Topic
7 replies Latest Post - ‏2013-07-15T07:05:03Z by Graham_Charters
Ravi's page
Ravi's page
12 Posts
ACCEPTED ANSWER

Pinned topic OSGI Configadmin in EBA

‏2013-07-10T13:51:12Z |

Hi All,

Can we use cm namespace for configure properties in application bundle (i.e bundle inside EBA)? when I tried getting  Bundle com.mycomp.bundle1 is waiting for dependencies [(objectClass=org.osgi.service.cm.ConfigurationAdmin)] error in log. org.osgi.service.cm package is not exposed in kernelCore-1.0.mf file.

config admin is working fine with user feature. If above answer is no, do I have to create new feature which reads config values and expose as a service, so that application bundle can read properties from service.

 
  • Graham_Charters
    Graham_Charters
    14 Posts
    ACCEPTED ANSWER

    Re: OSGI Configadmin in EBA

    ‏2013-07-11T09:47:00Z  in response to Ravi's page

    Hi Ravi,

    I don't quite follow some of your points, but I'll try to provide an answer, and if I've answered the wrong question, please clarify for me.

    By cm namespace, I believe you're referring to the Blueprint cm namespace.  Liberty doesn't support this, but you could try to add the Apache Aries Blueprint cm namespace handler to your User Feature which will enable the cm: namespace to be used in Blueprint in your EBA.  You could then provide configuration for the application via the server xml (you might want to do this via the include element to keep it separate), e.g, something like:

    <my.osgi.app.pid configProperty="configValue" />

    If you do this, I don't believe you should need direct access to the config admin service in your application.

    I hope this helps.

    Regards, Graham.

     

    • Ravi's page
      Ravi's page
      12 Posts
      ACCEPTED ANSWER

      Re: OSGI Configadmin in EBA

      ‏2013-07-11T13:33:16Z  in response to Graham_Charters

      Hi,

      Yes I am referring blueprint cm namespace. I don't think so, blueprint cm namespace is available as part of liberty profile. Please check blueprint-1.0.mf. 

      even it is working fine in feature bundles, but not working EBA bundles, 

      • Graham_Charters
        Graham_Charters
        14 Posts
        ACCEPTED ANSWER

        Re: OSGI Configadmin in EBA

        ‏2013-07-11T14:03:49Z  in response to Ravi's page

        Hi Ravi,

        This thread, and your other one around slf4j make me suspect you have two blueprint implementations (the one we provide in the Blueprint feature, and maybe one in one of your user features). If the Liberty Blueprint implementation is processing your feature bundles and handling the cm namespace, I don't know of any reason why it would decide it couldn't process your cm namespace inside the EBA.  It would be the same Blueprint container implementation with the same set of namespace handlers.  From what I know of your use case, I think there's a reasonable chance you do have two Blueprint implementations.  Could you check whether this is the case, and if so, see if you can remove the one from our user feature and have it use the Liberty Blueprint container instead?

        Regards, Graham.

        • Ravi's page
          Ravi's page
          12 Posts
          ACCEPTED ANSWER

          Re: OSGI Configadmin in EBA

          ‏2013-07-12T08:08:11Z  in response to Graham_Charters

          HI Graham,

          As part of my feature there is no cm namespace handler, even I logged into osgi console and verified cmnamespacehandler is registered only once from kernel. 

          I think problem is org.osgi.service.cm packages not part of IBM-API-Package list in kernelCore-1.0.mf. it is only part of IBM-SPI-Package.  this is not the good reason why cm namespace is not working in EBA, but working in feature?

          • Graham_Charters
            Graham_Charters
            14 Posts
            ACCEPTED ANSWER

            Re: OSGI Configadmin in EBA

            ‏2013-07-12T09:25:59Z  in response to Ravi's page

            Hi Ravi,

            I'm not aware of the cmnamespacehandler being provided by the kernel.  Would you be able to provide your user feature manifest?  Rather than suspecting the namespace handler, I was more wondering if you had a second Blueprint container.  Does your user feature contain any org.apache.aries.* bundles?  Would you be able to provide your subsystem manifest?

            I've not used the aries blueprint config admin support, but my understanding is the configuration is delivered to the namespace handler, which therefore needs to depend on org.osgi.service.cm, but it is then responsible for delivering the configurations based on the blueprints using the cm namespace.  Therefore, the blueprint bundles in your EBA don't depend directly on org.osgi.service.cm.  So having that package as an SPI should be sufficient.

            I think the first place I would look is to check that there's nothing in your user feature that might be 'conflicting' with what we provide in the OSGi application runtime.  I know that a number of open source projects like Camel, etc use the same Apache Aries technologies that we do.

            Regards, Graham.

             

            • Ravi's page
              Ravi's page
              12 Posts
              ACCEPTED ANSWER

              Re: OSGI Configadmin in EBA

              ‏2013-07-12T10:31:04Z  in response to Graham_Charters

              Hi Graham,

              Please find the attached file.

              I think this issue exists even I don't install my feature also, so mostly this is nothing to do with my feature.

              • Graham_Charters
                Graham_Charters
                14 Posts
                ACCEPTED ANSWER

                Re: OSGI Configadmin in EBA

                ‏2013-07-15T07:05:03Z  in response to Ravi's page

                Hi Ravi,

                I've been doing some digging and now know what's going on...

                Firstly, my apologies for what has turned out to be a red herring.  We are shipping what Apache Aries refers to as the Blueprint Uber bundle.  This is an amalgamation of a number of Blueprint bundles.  A consequence of this is we are shipping the cm namespace handlers, although it has never been used in Liberty (until now).

                I've reproduced the problem you are seeing with using the cm namespace inside an OSGi application (EBA).  What happens is the namespace handler augments the Blueprint model (what the Blueprint container creates from parsing the XML).  The handler adds a service dependency on the configuration admin service (which it does not have access to).  I believe it does this as a good practice - to tie their life-cycles such that if configuration admin is uninstalled, blueprints that use it will be taken down until a replacement is found.

                I then wondered what would happen if I added a config admin implementation to my application.  This solves the service dependency, but unfortunately, the namespace handler also adds a dependency on a bean implementation that is not visible to the application and so it fails a little later on.

                I don't see a way round this without a change to the runtime, so I would appreciate it if you could raise an RFE (www.ibm.com/developerworks/rfe/) for blueprint cm namespace support to be added.  As part of addressing this, we will want to consider any security implications (by default, the osgi application would have access to the whole server configuration).

                Sorry I wasn't able to find a solution at this time.

                Regards, Graham.