felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira ...@odoko.co.uk>
Subject Re: URL Handlers Service
Date Mon, 03 Oct 2005 18:18:08 GMT
Richard S. Hall wrote:
> Yes, Niclas raises a very good point, too. I would not be high on 
> modifying the byte code of URL...seems overly risky.

Okay. I'll mull some more. :-)

Regards, Upayavira

> 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
>>
>>
>>
>>  
>>
> 


Mime
View raw message