[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Possible to obtain org.eclipse.osgi.jar without OSGi framework classes?

Hi Jeff,
I'm trying to integrate Equinox as a JCA adapter into WLS 9.2 which, to the best of my knowledge, is not based on OSGi, as opposed to WLS 10.0. Anyway, my goals are the following:
- Keep the application's main programming model, migrate to OSGi only those very few yet very sensitive parts of the application that change very often. This application is a _massive_ J2EE app which has been in the works since 2001. We are still working on finishing the first iteration.
- Statically define a set of service interfaces whose implementation will be provided at runtime by Equinox. These interfaces live in a jar which is visible to both the enclosing JCA adapter module as well as Equinox. The packages these interfaces reside in are listed among OSGi's system packages.
- Keep Equinox' class space(s) almost completely isolated from that of the enclosing JCA adapter module's.
- Expose the org.osgi.framework classes - and later possibly the packageadmin's classes - to the enclosing JCA adapter module so that accessing OSGi services becomes possible. The org.osgi.framework package is listed among OSGi's system packages.
When bootsrapping Equinox from inside the JCA adapter, I create a new child first classloader as a child classloader of the classloader that loaded the JCA module. This child first classloader knows about the location of the org.eclipse.osgi.jar on the classpath and first tries to load classes from this jar before delegating to the parent classloader, thus isolating the Equinox implementation from the enclosing JCA adapter module. This works like a charm:
     JCA RAR ClassLoader                  --------->      service-interfaces.jar
     ChildFirstBootstrapClassLoader     --------->      org.eclispe.osgi.jar
Unfortunately, since the OSGi framework is included in org.eclispe.osgi.jar, this also means that the org.osgi.framework classes will be loaded by this child first classloader and will therefore not be visible to the enclosing JCA adapter module. I tried patching the child first classloader to not loading classes that start with "org.osgi.framework" - I consider this solution an ugly hack - and putting osgi_R4.jar on the JCA adapter module's classpath. This doesn't work since it gives me a NoSuchMethodError: Equinox cannot find the method Bundle.start(). I am no classloading expert but suspect that there are two Bundle classes loaded. Of course, I could be totally wrong.
Anyway, after several fruitless hours of debugging I decided not to venture further down this path and opted for a solution that uses reflection to gain access to the BundleContext returned from EclipseStarter.startup(). This works yet feels a little clumsy. If someone could point me to means of achieving my original goal of sharing the OSGi API classes between Equinox and the enclosing JCA adapter module, I would be grateful.
Hey Olaf,

The short answer is, No, such a distribution is not readily available.

The question in my mind is why do you need this? If you remove the OSGi classes where will they come from? If you happen to be running on an OSGi-based JEE app server then you could in theory get the classes from the app server. To do this you should be able to play around with the framework's parent classloader. That way the OSGi classes would still be in the org.eclipse.osgi bundle but they would be ignored in favor of the ones from the parent loader.


Olaf Bergner wrote:

I'm currently embedding equinox into a JEE app server and would like to make
the OSGi API visible to the enclosing application. Therefore, I need an
org.eclipse.osgi distribution that does not include the org.osgi.framework
classes. Does it exist?


equinox-dev mailing list