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

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

    Re: OSGI Configadmin in EBA

    ‏2013-07-11T09:47:00Z  

    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

    Re: OSGI Configadmin in EBA

    ‏2013-07-11T13:33:16Z  

    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.

     

    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

    Re: OSGI Configadmin in EBA

    ‏2013-07-11T14:03:49Z  

    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, 

    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

    Re: OSGI Configadmin in EBA

    ‏2013-07-12T08:08:11Z  

    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.

    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

    Re: OSGI Configadmin in EBA

    ‏2013-07-12T09:25:59Z  

    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?

    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

    Re: OSGI Configadmin in EBA

    ‏2013-07-12T10:31:04Z  

    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.

     

    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

    Re: OSGI Configadmin in EBA

    ‏2013-07-15T07:05:03Z  

    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.

    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.