Re: [equinox-dev] Possible problem with classloaders

[Niclas Hedhman <niclas@xxxxxxxxxxx>]

On Tuesday 12 December 2006 21:09, AC wrote:
> I have some problems using equinox bundles and I am hoping somebody here
> can point me to how to do it. I'm trying to implement a custom protocol
> handler in an equinox bundle

If Thomas answer is not clear enough.
The above mechanism has a behavior due to a bug (regression) introduced 
somewhere around 1997 (IIRC), where an additional level of methods was 
introduced between a method in java.net.URLClassloader and the Sun private 
class sun.misc.URLClassPath. Sun insist of not trying to fix this, 
using "Security Concerns" as the argument.

That led to that the intention of using the classloader of the caller (the URL 
implementation) in URLClassPath changed so that the java.net.URL classloader 
is used instead, which is always null, and if null --> use the System 
Classloader.

Therefor, all URL handler that wants to use the java.protocol.handler.pkgs 
property MUST sit in the system classloader or in the extension classloader.


OSGi doesn't use this, and instead relies on the URLStreamHandlerFactory. The 
downside there is that only ONE handler can be registered through-out the JVM 
lifetime. So therefor, OSGi introduced its own extension so that bundles can 
register handlers, and the OSGi URLStreamHandlerFactory implementation will 
delegate. This should allow for runtime replacable implementations. Since the 
URLStreamHandler for each protocol is cached in java.net.URL (see method 
getURLStreamHandler( String protocol ) ), the OSGi framework implementation 
(see chapter 11, R4 Core) MUST wrap the actual implementation with a 
facade/proxy that will remain cached and so that the protocol implementation 
can be replaced.
This responsibility lies on the OSGi framework implementors.


Cheers
Niclas