search

ContainX / openstack4j

A Fluent OpenStack SDK / Client Library for Java
http://openstack4j.com
Other
290 stars 368 forks source link

Add OSGi support to JARs #214

Open logoff opened 9 years ago

logoff commented 9 years ago

It would be very useful adding OSGi support in project JARs. Now it is not possible adding project JARs (and dependencies) into and OSGi platform (like Apache Felix or Eclipse Equinox).

Adding support to OSGI is very easy using Apache Felix Maven Bundle Plugin.

Finally, creating a Apache Karaf Feature would ease the job of adding the project as dependency in Apache Karaf.

Some of the project dependencies are OSGi compatible but there is a mess in their dependency chain (import and export relations are not correct at all!).

gondor commented 9 years ago

I would love to have support for OSGI in OpenStack4j. In my engineering path I've haven't had an environment that leveraged it, so I'm not that versed in it. Is this something you'd want to contribute? If not I may have more questions if I look into this.

isartcanyameres commented 9 years ago

Hi, I'm currently working on this feature.

The steps I'm following:

I'll rise any question I may have using the openstack4j group

gondor commented 9 years ago

Great, thank you! I just saw your question in the group. I'll provide a few answers and as well I can call out who recently did the yaml work so they can respond on those questions.

isartcanyameres commented 9 years ago

Although previous patches prepare openstack4j to be depoyed in OSGi environments, currently openstack4j is not yet functional in OSGi.

Currently, openstack4j-core cannot be resolved in OSGI as it makes use of a package that is not visible in OSGi environments.

TODO: Find an alternative implementation for org.openstack4j.openstack.heat.utils.Environment.java and org.openstack4j.openstack.heat.utils.Template.java without importing packages that are not visible in OSGi. Please see the conversation about using not visible package

mhshams commented 9 years ago

One more point regarding OSGi support: HttpExecutor is using Java ServiceLoader to find out the connector: 

Iterator<HttpExecutorService> it = ServiceLoader.load(HttpExecutorService.class).iterator();

This solution won't work in OSGi environment, because each bundle ( Jar file in this context) has it's own class loader.

isartcanyameres commented 9 years ago

Hi, ServiceLoader mechanism is supported in OSGi by using SPI Fly dynamic weaving bundle. However, this bundle must be in your OSGi container. In case you are using karaf you can make use of the already defined features to install it.

For that to work, bundles must declare (in manifest file) to import/export some capabilities, as explained here: http://aries.apache.org/modules/spi-fly.html#specconf

Openstack4j bundles are now declaring those capabilities in their manifest file as introduced in #242. This is done by means of maven-bundle-plugin configuration in each pom.xml file (e.g. see httpclient pom.xml)

timothyjward commented 7 years ago

ServiceLoader mechanism is supported in OSGi by using SPI Fly dynamic weaving bundle. However, this bundle must be in your OSGi container.

This is true, however it only works for the default usage of ServiceLoader (i.e. when you don't pass a ClassLoader). This is because the specification works by setting the TCCL to one with visibility of the correct types. The change https://github.com/ContainX/openstack4j/commit/64e1857adea38b008083dd0ba5cef565389bf2f8 (from October 2015) changed this usage, and broke OpenStack4j's OSGi support.

This failure would have been pretty obvious if there were any OSGi integration tests for OpenStack4j. I can recommend the bnd-testing-maven-plugin or PAX-Exam. Both would be relatively easy to add to the build, and would prevent regressions like this one.