Eclipse Community Forums: Equinox » some more classloader challanges

Help

Home

Home » Eclipse Projects » Equinox » some more classloader challanges

Show: Today's Messages :: Show Polls :: Message Navigator

some more classloader challanges [message #90154]

Mon, 11 June 2007 16:12

Martin Lippert

Messages: 124
Registered: July 2009

Senior Member

Hi!

I have a really tough classloading challange to solve and I hope someone
on this group can help me. I have the following situation:

1. general java app has a lot of libraries in its classpath. Unfortunately
xercesImpl.jar is one of these. Running with JDK 1.6.

2. this app creates a classloader (app loader as parent) and loads some
startup classes. This loader has startup.jar in its path (Eclipse 3.2).

3. one of these startup classes calls Main.main to start the OSGi runtime.
The CCL is cut off.

My goal: The OSGi runtime itself and all the bundles running inside the
OSGi runtime should use the XML parser of the JDK and not the Xerces
implementation.

What happens is that the OSGi implementation (and other bundles) request
an XML parser via the default JDK mechanism
(javax.xml.parsers.SAXParserFactory). The default JDK implementation looks
for some parser definition files in META-INF directories and finds
(unfortunately) the xercesImpl.jar-Definition (via the system class
loader) even if the parent loader of the CCL is set to null (boot).

For me it seems like it is not possible to force the OSGi runtime (and
other bundles) to use the JDKs XML parser if there is xercesImpl on the
app classpath... This seems strange to me...

Any ideas?

Side note: I am not allowed to change the system class path or set some
system properties for XML parsing... :-(

Thank you very very much for your help!!!

Cheers,
-Martin

Report message to a moderator

Re: some more classloader challanges [message #90478 is a reply to message #90154]

Wed, 13 June 2007 18:40

Thomas Watson

Messages: 503
Registered: July 2009

Senior Member

The SAXParserFactory.newInstance ends up using the app classloader
instead of the context class loader? That is not what I would expect.
Do you know if that is new to JDK 1.6? Is it only using it as a last
resort after consulting the CCL?

There is really nothing we can do from OSGi to isolate the JRE from
stuff shoved on the app classloader. But I find it strange that the
SAXParserFactory from the VM is using the app classloader by default
instead of the CCL.

Tom.

Report message to a moderator

Re: some more classloader challanges [message #90627 is a reply to message #90478]

Thu, 14 June 2007 08:28

Martin Lippert

Messages: 124
Registered: July 2009

Senior Member

Hi Tom,

the JDK mechanism first consults the CCL to find the properties and uses
the system class loader as fallback (you are completely right). So we need
to somehow allow the ContextFinder to find some self-defined property
files that define the JDK parsers as the ones to use. Should be somehow
possible... :-)

Thanks!!!
-Martin

Report message to a moderator

Re: some more classloader challanges [message #90668 is a reply to message #90627]

Thu, 14 June 2007 15:13

Thomas Watson

Messages: 503
Registered: July 2009

Senior Member

Try setting osgi.contextClassLoaderParent=fwk and using a framework
extension bundle to add the self-defined property files to the
framework's classloader. Would that work? That should allow
ContextFinder to find the property files located in the framework
extension bundle which is accessed through the framework's classloader.

Tom

Report message to a moderator

Re: some more classloader challanges [message #90711 is a reply to message #90668]

Thu, 14 June 2007 20:25

Martin Lippert

Messages: 124
Registered: July 2009

Senior Member

Hi Tom,

oh yes, good idea, that should work for this case!

Unfortunately we currently set osgi.contextClassLoaderParent=ccl to
allow our starter bundle to access some specific communication classes
from outside the OSGi world. But I don't like this solution at all. I
think using EclipseStarter directly instead of the startup.jar
(operating in the old 3.2 world) would make things somewhat easier. Then
I could try to use framework extension bundles to export some outside
classes for other bundles a lot easier I think.

Thanks again!!!
-Martin

> Try setting osgi.contextClassLoaderParent=fwk and using a framework
> extension bundle to add the self-defined property files to the
> framework's classloader. Would that work? That should allow
> ContextFinder to find the property files located in the framework
> extension bundle which is accessed through the framework's classloader.

Report message to a moderator

Previous Topic:	CCL and the Swing event queue
Next Topic:	equinox jetty in RCP

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Wed Jan 15 06:50:23 GMT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter