Sling
  1. Sling
  2. SLING-2450

JcrInstaller generates incorrect node name in /apps/system/config (or else the installer doesn't process the nodename properly)

    Details

      Description

      when using ConfigurationAdmin or osgi web console to create a config for a ManagedServiceFactory, a nt:file node is created in /apps/system/config with a node name like:
      com.adobe.granite.auth.oauth.provider.com.adobe.granite.auth.oauth.provider.99bd39e3-4367-47b0-a5a2-b4e1a0f8a5b9.config

      The installer, however will not process the node (and create the managed service propertly) unless the node name is formatted like:
      com.adobe.granite.auth.oauth.provider-99bd39e3-4367-47b0-a5a2-b4e1a0f8a5b9.config

      Note that:

      • "com.adobe.granite.auth.oauth.provider" string only occurs once
      • there is a dash "-" after "provider"

      I'm not sure which problem it is, but it may be one of:

      • the JcrInstaller generates the wrong node name
      • OR the JcrInstaller does not process the node name properly

        Activity

        Hide
        Carsten Ziegeler added a comment -

        Finally fixed with 1338272. This last change affects only the configuration factory

        Show
        Carsten Ziegeler added a comment - Finally fixed with 1338272. This last change affects only the configuration factory
        Hide
        Carsten Ziegeler added a comment -

        It seems that there is still a problem, when a factory configuration is created through the web console and later changed in the repository. This ends up with two
        factory configurations.

        Show
        Carsten Ziegeler added a comment - It seems that there is still a problem, when a factory configuration is created through the web console and later changed in the repository. This ends up with two factory configurations.
        Hide
        Carsten Ziegeler added a comment -

        Hi Tyson,

        I'm closing this bug for two reasons:

        • the problem you describe is not the same than this issue; it's about reading configurations not writing them back
        • I did a quick test and adding config files to the repo, editing them etc. works for me

        If you think there still is an issue, please create a new issue with a description how to reproduce the problem. Thanks

        Show
        Carsten Ziegeler added a comment - Hi Tyson, I'm closing this bug for two reasons: the problem you describe is not the same than this issue; it's about reading configurations not writing them back I did a quick test and adding config files to the repo, editing them etc. works for me If you think there still is an issue, please create a new issue with a description how to reproduce the problem. Thanks
        Hide
        Tyson Norris added a comment -

        @Bertrand : The tests exercise sling:OsgiConfig triggering osgi config, which works; I'm looking for how to rely on the new nt:file (which replaces sling:OsgiConfig after installation) can cause the osgi config.

        @Carsten : "The jcr installer part ignoring those nodes is correct" - current behavior is the sling:OsgiConfig nodes disappear after installation, which is fine I guess, as long as the nt:file node that appears in its place is used. In the case where to separate instances are supposed to reflect changes by copying content from one to the other, this means that copying the nt:file should cause changes to appear in the second instance, but that is not the case. How else should a config generated on one instance get copied to another instance?

        The only possibility I see with current system is to monitor configuration changes myself, and generate sling:OsgiConfig myself manually, and copy that to the second instance for installation. ack.

        Thanks
        Tyson

        Show
        Tyson Norris added a comment - @Bertrand : The tests exercise sling:OsgiConfig triggering osgi config, which works; I'm looking for how to rely on the new nt:file (which replaces sling:OsgiConfig after installation) can cause the osgi config. @Carsten : "The jcr installer part ignoring those nodes is correct" - current behavior is the sling:OsgiConfig nodes disappear after installation, which is fine I guess, as long as the nt:file node that appears in its place is used. In the case where to separate instances are supposed to reflect changes by copying content from one to the other, this means that copying the nt:file should cause changes to appear in the second instance, but that is not the case. How else should a config generated on one instance get copied to another instance? The only possibility I see with current system is to monitor configuration changes myself, and generate sling:OsgiConfig myself manually, and copy that to the second instance for installation. ack. Thanks Tyson
        Hide
        Bertrand Delacretaz added a comment -

        Aren't there any automated tests that demonstrate that this functionality works?

        Show
        Bertrand Delacretaz added a comment - Aren't there any automated tests that demonstrate that this functionality works?
        Hide
        Tyson Norris added a comment -

        reopening because I still have the problem;

        Wondering if I am misunderstanding the change from sling:OsgiConfig to nt:file - adding a sling:OsgiConfig should cause the config to register via ConfigurationManager, does the same not work for adding an nt:file into a config folder?

        Show
        Tyson Norris added a comment - reopening because I still have the problem; Wondering if I am misunderstanding the change from sling:OsgiConfig to nt:file - adding a sling:OsgiConfig should cause the config to register via ConfigurationManager, does the same not work for adding an nt:file into a config folder?
        Hide
        Tyson Norris added a comment - - edited

        I built snapshot versions:
        rw-rr- 1 tnorris admin 130504 Apr 25 13:55 org.apache.sling.installer.core-3.3.5-SNAPSHOT.jar
        rw-rr- 1 tnorris admin 24185 Apr 25 13:57 org.apache.sling.installer.factory.configuration-1.0.5-SNAPSHOT.jar
        rw-rr- 1 tnorris admin 54277 Apr 25 13:56 org.apache.sling.installer.provider.jcr-3.1.3-SNAPSHOT.jar

        Then installed into crx; verified the bundle versions in osgi console.

        But don't see any change when I try have the text file resurrect the osgi config on a different instance.

        Adding a node at /apps/system/config/com.adobe.granite.auth.oauth.provider.com.adobe.granite.auth.oauth.provider.514f1954-94c8-48b1-bc65-f96c794a37ce.config should produce a config for provider com.adobe.granite.auth.oauth.provider right?

        Thanks
        Tyson

        Show
        Tyson Norris added a comment - - edited I built snapshot versions: rw-r r - 1 tnorris admin 130504 Apr 25 13:55 org.apache.sling.installer.core-3.3.5-SNAPSHOT.jar rw-r r - 1 tnorris admin 24185 Apr 25 13:57 org.apache.sling.installer.factory.configuration-1.0.5-SNAPSHOT.jar rw-r r - 1 tnorris admin 54277 Apr 25 13:56 org.apache.sling.installer.provider.jcr-3.1.3-SNAPSHOT.jar Then installed into crx; verified the bundle versions in osgi console. But don't see any change when I try have the text file resurrect the osgi config on a different instance. Adding a node at /apps/system/config/com.adobe.granite.auth.oauth.provider.com.adobe.granite.auth.oauth.provider.514f1954-94c8-48b1-bc65-f96c794a37ce.config should produce a config for provider com.adobe.granite.auth.oauth.provider right? Thanks Tyson
        Hide
        Carsten Ziegeler added a comment -

        Actually this was a serious of smaller bugs in all three components. I've fixed the factory configuration handling in revision 1307172. In addition it now uses the alias name when writing back an overwritten configuration

        Show
        Carsten Ziegeler added a comment - Actually this was a serious of smaller bugs in all three components. I've fixed the factory configuration handling in revision 1307172. In addition it now uses the alias name when writing back an overwritten configuration
        Hide
        Carsten Ziegeler added a comment -

        This seems to be a bug/problem in the osgi installer core which does not translate factory pids correctly back.
        The jcr installer part ignoring those nodes is correct

        I'll have to investigate a little bit here

        Show
        Carsten Ziegeler added a comment - This seems to be a bug/problem in the osgi installer core which does not translate factory pids correctly back. The jcr installer part ignoring those nodes is correct I'll have to investigate a little bit here
        Hide
        Tyson Norris added a comment -

        In my test, adding a node to /apps/system/config named in the same way as the generated node (e.g. com.adobe.granite.auth.oauth.provider.com.adobe.granite.auth.oauth.provider.955d9a39.10ad9a1b-d610-4c18-a816-4a774dfcb2cf.config) results in this log message, with an incorrect service.factoryPid:
        28.03.2012 10:26:24.422 INFO [OsgiInstallerImpl] org.apache.sling.audit.osgi.installer Installed configuration com.adobe.granite.auth.oauth.provider.com.adobe.granite.auth.oauth.provider.955d9a39.10ad9a1b-d610-4c18-a816-4a774dfcb2cf from resource TaskResource(url=jcrinstall:/apps/system/config/com.adobe.granite.auth.oauth.provider.com.adobe.granite.auth.oauth.provider.955d9a39-9231-43e8-9d67-11111111.config, entity=config:com.adobe.granite.auth.oauth.provider.com.adobe.granite.auth.oauth.provider.955d9a39.9231-43e8-9d67-11111111, state=INSTALL, attributes=[org.apache.sling.installer.api.tasks.ResourceTransformer=:50:, service.factoryPid=com.adobe.granite.auth.oauth.provider.com.adobe.granite.auth.oauth.provider.955d9a39, service.pid=9231-43e8-9d67-11111111], digest=5abc3a8c9c399d8d9d510641ab388577)

        If instead I name a node com.adobe.granite.auth.oauth.provider-955d9a39-9231-43e8-9d67-11111111.config, the correct factoryPid is used and config appears as expected:
        28.03.2012 10:44:17.349 INFO [OsgiInstallerImpl] org.apache.sling.audit.osgi.installer Installed configuration com.adobe.granite.auth.oauth.provider.618f4315-4a0d-4ede-9657-0e32e0215d83 from resource TaskResource(url=jcrinstall:/apps/system/config/com.adobe.granite.auth.oauth.provider-955d9a39-9231-43e8-9d67-11111111.config, entity=config:com.adobe.granite.auth.oauth.provider.955d9a39-9231-43e8-9d67-11111111, state=INSTALL, attributes=[org.apache.sling.installer.api.tasks.ResourceTransformer=:50:, service.factoryPid=com.adobe.granite.auth.oauth.provider, service.pid=955d9a39-9231-43e8-9d67-11111111], digest=65741728327d3b692b0272c53691a04a)

        Show
        Tyson Norris added a comment - In my test, adding a node to /apps/system/config named in the same way as the generated node (e.g. com.adobe.granite.auth.oauth.provider.com.adobe.granite.auth.oauth.provider.955d9a39.10ad9a1b-d610-4c18-a816-4a774dfcb2cf.config) results in this log message, with an incorrect service.factoryPid: 28.03.2012 10:26:24.422 INFO [OsgiInstallerImpl] org.apache.sling.audit.osgi.installer Installed configuration com.adobe.granite.auth.oauth.provider.com.adobe.granite.auth.oauth.provider.955d9a39.10ad9a1b-d610-4c18-a816-4a774dfcb2cf from resource TaskResource(url=jcrinstall:/apps/system/config/com.adobe.granite.auth.oauth.provider.com.adobe.granite.auth.oauth.provider.955d9a39-9231-43e8-9d67-11111111.config, entity=config:com.adobe.granite.auth.oauth.provider.com.adobe.granite.auth.oauth.provider.955d9a39.9231-43e8-9d67-11111111, state=INSTALL, attributes= [org.apache.sling.installer.api.tasks.ResourceTransformer=:50:, service.factoryPid=com.adobe.granite.auth.oauth.provider.com.adobe.granite.auth.oauth.provider.955d9a39, service.pid=9231-43e8-9d67-11111111] , digest=5abc3a8c9c399d8d9d510641ab388577) If instead I name a node com.adobe.granite.auth.oauth.provider-955d9a39-9231-43e8-9d67-11111111.config, the correct factoryPid is used and config appears as expected: 28.03.2012 10:44:17.349 INFO [OsgiInstallerImpl] org.apache.sling.audit.osgi.installer Installed configuration com.adobe.granite.auth.oauth.provider.618f4315-4a0d-4ede-9657-0e32e0215d83 from resource TaskResource(url=jcrinstall:/apps/system/config/com.adobe.granite.auth.oauth.provider-955d9a39-9231-43e8-9d67-11111111.config, entity=config:com.adobe.granite.auth.oauth.provider.955d9a39-9231-43e8-9d67-11111111, state=INSTALL, attributes= [org.apache.sling.installer.api.tasks.ResourceTransformer=:50:, service.factoryPid=com.adobe.granite.auth.oauth.provider, service.pid=955d9a39-9231-43e8-9d67-11111111] , digest=65741728327d3b692b0272c53691a04a)

          People

          • Assignee:
            Carsten Ziegeler
            Reporter:
            Tyson Norris
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development