Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0
    • Fix Version/s: 2.0.0-RC2
    • Component/s: Java, Javascript
    • Labels:
      None

      Description

      Digging through the code; I have a test gadget that displays the compliance level of a javascript container. It is available at http://henning.schmiedehausen.org/gadgets/check.xml. This loads all opensocial features as optional and then displays the results of hasFeature(), which should only be true if a feature actually exists.

      Consider me surprised, when this gadget found out that most popular containers already support opensocial-1.0.

      The current shindig code builds an array of features from the gadget in RenderingContentRewriter.java:354. For all features referenced by the gadget, this will contain an entry with the configuration. Even for the ones that are optional.

      in core.io/utils.js, the hasFeature() method only tests the presence of a key in this array. Which is always present if a feature is referenced by the gadget spec. No matter whether it exists or not. It will always report the feature existing. As the Optional/hasFeature combo is the only way to find out whether a given feature requested by a gadget is actually present, I consider this a bug.

      1. SHINDIG-803.patch
        2 kB
        Henning Schmiedehausen

        Issue Links

          Activity

          Hide
          Henning Schmiedehausen added a comment -

          This is the q'n'd patch to the core that puts only the elements into the core.utils map that are actually present on the feature registry. This might break things like transitive dependencies, but then again, a config object that was only referenced through transitive dependencies was never put into this array in the first place. Which might be a bug onto itself...

          Show
          Henning Schmiedehausen added a comment - This is the q'n'd patch to the core that puts only the elements into the core.utils map that are actually present on the feature registry. This might break things like transitive dependencies, but then again, a config object that was only referenced through transitive dependencies was never put into this array in the first place. Which might be a bug onto itself...
          Hide
          Kevin Brown added a comment -

          Transitive does need to work, so that features like core.io have their configuration pulled in correctly. That's independent from whether or not the feature names are added to the core.util feature map though.

          Show
          Kevin Brown added a comment - Transitive does need to work, so that features like core.io have their configuration pulled in correctly. That's independent from whether or not the feature names are added to the core.util feature map though.
          Hide
          Kevin Brown added a comment -

          Do you want to unify this with your other patch to customize contributors to gadgets.config? It seems like it should be.

          Show
          Kevin Brown added a comment - Do you want to unify this with your other patch to customize contributors to gadgets.config? It seems like it should be.
          Hide
          Henning Schmiedehausen added a comment -

          Yes; in fact this should already be part of that patch.

          Show
          Henning Schmiedehausen added a comment - Yes; in fact this should already be part of that patch.
          Hide
          Henning Schmiedehausen added a comment -

          Applying the updated SHINDIG-805 patch will also fix this bug.

          Show
          Henning Schmiedehausen added a comment - Applying the updated SHINDIG-805 patch will also fix this bug.
          Hide
          Nenad Nikolic added a comment -

          Before reporting the same problem, I did a search and - sure enough, someone noticed this a while ago.

          Anyway, incidentally I've developed together with my colleague a similar feature test gadget. It actually goes around this bug in Shindig, checks for available features anyway and correctly finds what features are available without having to use hasFeature. This gadget is appropriately called FIG (Feature Inspection Gadget).

          Here's it is:
          http://shonzilla.com/gadgets/fig.xml

          Show
          Nenad Nikolic added a comment - Before reporting the same problem, I did a search and - sure enough, someone noticed this a while ago. Anyway, incidentally I've developed together with my colleague a similar feature test gadget. It actually goes around this bug in Shindig, checks for available features anyway and correctly finds what features are available without having to use hasFeature. This gadget is appropriately called FIG (Feature Inspection Gadget). Here's it is: http://shonzilla.com/gadgets/fig.xml
          Hide
          Paul Lindner added a comment -

          fixed! had to rewrite the patch to support the new classes..

          Show
          Paul Lindner added a comment - fixed! had to rewrite the patch to support the new classes..

            People

            • Assignee:
              Unassigned
              Reporter:
              Henning Schmiedehausen
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development