Mailing-List: contact oscar-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oscar-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <434175E0.7060900@odoko.co.uk>
Date: Mon, 03 Oct 2005 19:18:08 +0100
From: Upayavira <uv@odoko.co.uk>
Organization: Odoko Ltd
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050912)
MIME-Version: 1.0
To: oscar-dev@incubator.apache.org
Subject: Re: URL Handlers Service
References: <NBBBJGEAGJAKLIDBKJOPKEGKDMAC.noel@devtech.com>
 <4341444E.5010409@ungoverned.org> <43414587.8080903@odoko.co.uk>
 <200510032339.35065.niclas@apache.org> <434169B9.30409@ungoverned.org>
In-Reply-To: <434169B9.30409@ungoverned.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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