2 Replies Latest reply: Apr 27, 2012 9:49 AM by Sergio Castro RSS

Making bundle classes accessible to any application deployed in JBoss 7


I have an OSGI bundle and I would like that classes in its exported packages can be accessible to all the applications deployed in my jboss server.

I have found instructions explaining how to do this using JBoss modules instead (https://docs.jboss.org/author/display/AS7/Class+Loading+in+AS7#ClassLoadinginAS7-GlobalModules), but I have not been able to find the steps to do the same with OSGI bundles.

What I am doing right now is to deploy the OSGI bundle in the JBOSS_HOME/standalone/deployments folder, together with my applications, and then per each application I am adding to its

MANIFEST.MF file this line: Dependencies: deployment.<OSGIBundleName>:<OSGIBundleVersion>. This last step (changing the manifest of each deployed application) is the one that I am trying to avoid.


I have tried installing the bundle in the JBoss "bundles" folder, but I have not been able to find out the additional steps to configure JBoss so classes in its exported packages will be accessible to deployed applications.


Thanks in advance for any help!.

  • 1. Re: Making bundle classes accessible to any application deployed in JBoss 7
    Thomas Diesler Master

    It is a fundamental principal of modularity that the consumer (of a package) defines its depenencies i.e. it is not wired automatically to everything else.


    Another option could possibly be jboss-deployment-structure.xml


    [tdiesler@tdvaio jboss-as]$ find . -name jboss-deployment-structure.xml


    The standard option would be to stick to OSGi bundle deployments only. What would be preventing you to do that?


    Starting from 7.1.2 (07-May-2012) non OSGi deployments are automatically registered with resolver environment. So you could put your APIs in a jar and import them from your bundle.

  • 2. Re: Making bundle classes accessible to any application deployed in JBoss 7

    Thanks for replying Thomas.


    Yes, I have an additional constraint for not deploying my OSGI bundle in the deployments folder. One of its components is JPL, a Java library using JNI to interact with a Prolog engine.

    If I deploy the bundle in the deployments folder, after any modifications in the applications clients of my bundle, I get a:


    "... java.lang.UnsatisfiedLinkError: Native Library /usr/local/lib/Yap/libjpl.dylib already loaded in another classloader"


    And the only thing I can do is to restart the server.

    As far as I understood, the solution to this problem is to somehow deploy the bundle "globally", so it will be loaded only once and the UnsatisfiedLinkError error will not occur.

    Trying to do this, I followed the procedure to deploy a global module, but using my OSGI bundle jar as the only jar in the module, just to see what would happen. To my surprise, this kind of work, I was able to access classes inside my bundle (without having to declare the dependency in the MANIFEST.MF file of the client applications).


    Unfortunately, I observed that in these two cases (both when deploying the bundle locating it in the "deployments" folder, or when deploying it as a global JBoss module), I sill had the problem of the UnsatisfiedLinkError error when modifying classes in clients of the OSGI bundle.

    In both cases I also observed an additional problem: the "Export-Package" directive in the bundle manifest file is ignored, and the client applications are able to see all the classes in the bundle, not only classes in the exported packages as expected. As far as I understand this could lead to conflicts if the client applications are using different versions of a library that is also present in the bundle, is this correct ?.


    The only partial solution I have found to my problem is to separate the JPL library from the rest of my OSGI bundle and then publishing only this library as a global JBoss module. For some reason, if only this library is deployed alone as a global module (instead of my entire OSGI bundle), then I do not have anymore the UnsatisfiedLinkError error. I am not happy with this solution since the installation of my application starts to get complex. I think it should be a way to deploy an OSGI bundle such that I know its classes will be loaded only once by the application server (avoiding in this way issues with JNI), and that its non exported packages are not accessible to client aplications.


    Thanks for any help on this!