Yes, Niclas raises a very good point, too. I would not be high on
modifying the byte code of URL...seems overly risky.
-> richard
Niclas Hedhman wrote:
On Monday 03 October 2005 22:51, Upayavira wrote:
Okay. What I have in mind is that, outside of OSGi, they can do what
they like - talk to the System classloader, etc. Inside of OSGi, we do
what _we_ like, i.e. override the standard URL class as necessary. That
way, a Felix app can run alongside another app in a container when both
set StreamHandlers. But the non-OSGi app wouldn't need to know anything
about OSGi's stream handlers, in fact, much better that it doesn't.
I have previously tried to replace simpler classes in the rt.jar, and always
got Errors from the JVM complaining that something malicious is going on.
Perhaps I was unlucky, but I suspect some minimum checks are in place...
Well, even if that is not the case or that we can circumvent that somehow, how
about this next scenario;
// Fetch the felix classloader "somehow" like;
FelixClassLoader fcl = getClass().getClassLoader();
// The FelixClassLoader will intercept the findClass()
// method, and load the URL.class from upayavira.jar :o)
URL mine = new URL( "mine://abc" );
// URL array, which is in the FelixClassloader namespace
// for the reasons of above.
URL[] urls = new URL[] { mine };
// Creating a URLClassLoader, which will be loaded by the
// bootstrap classloader, and load the URL.class from
// rt.jar.
// Then an assignment of
// rt:URL[] = upayavira:URL[]
// will fail due to incompatible namespace, and a NoClassDefError
// will be thrown.
URLClassLoader ucl = new URLClassLoader( urls, parent );
I.e. Any JDK class that takes or returns a URL, will not work with the
URL.class that is loaded 'specially'.
But we could of course limit ourselves to JDK 1.1.x and I think we have a
better chance. ;o)
Cheers
Niclas
