[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] Possible problem with classloaders
- From: Niclas Hedhman <niclas@xxxxxxxxxxx>
- Date: Fri, 15 Dec 2006 11:20:05 +0800
- Delivered-to: email@example.com
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=XuJCZgHq6lc5djDUcdKKMg5WUEYNrg0DIB9Yy+GA/26YhdxoxggUdJwKiDT6v8d8+LDYr8HF32p34OMW85s7enPJ6yOLhTaOWaKw4VMyk+dLS7jPllYQzPjqNY4nQCGu+T71PcMilAWQ1rjQNa9ShHrWgqRA9pV5rYVqrqaH00g=
- User-agent: KMail/1.9.5
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
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.