felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: URL Handlers Service
Date Mon, 03 Oct 2005 17:26:17 GMT
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)

View raw message