AW: [equinox-dev] Possible to obtain org.eclipse.osgi.jar withoutOSGi fr

["Olaf Bergner" <olaf.bergner@xxxxxx>]

Hi Jeff,

thanks for your tireless efforts. I managed to make my scenario work by
repackaging org.eclipse.osgi.jar, stripping all org.osgi packages and
declaring corresponding imports in the repackaged jar's Import-Package
header. Now, I'm by no stretch of the imagination an expert on legal
matters, let alone the arcanae of licensing issues and fully expect this
rogue measure to gain me a prolonged free lunch in some state prison, yet
for the time being I will live with this threat and prod happily further
down this path.

BTW: Pending my employer's permission, I plan to someday make this little
pet project of mine open source. Do you think people would be interested?

Cheers,
Olaf

________________________________________
Von: equinox-dev-bounces@xxxxxxxxxxx
[mailto:equinox-dev-bounces@xxxxxxxxxxx] Im Auftrag von Jeff McAffer
Gesendet: Freitag, 4. Juli 2008 15:09
An: Equinox development mailing list
Betreff: Re: [equinox-dev] Possible to obtain org.eclipse.osgi.jar
withoutOSGi framework classes?

Hey Olaf

Did you try copying out the OSGi types and putting them on the JCA
classloader?  If the FirstChild is actually a child of the JCA loader then
it should get the OSGi types from JCA and ignore the ones in the osgi.jar. 
Of course, if you are trying to isolate Equinox from the JCA classes this
might be a problem.  What is the parent of the JCA classloader?  
Jeff

Bergner, Olaf wrote: 
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.
 
Cheers,
Olaf 
 
----------------------------------------------------------------------------
------------------------------
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.
Jeff

Olaf Bergner wrote: 
Hello,

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?

Cheers,
Olaf

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev

________________________________________

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev