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 14:08:19 GMT
Richard S. Hall wrote:
> Upayavira wrote:
>> No, actually it is intended to fix the problem caused by a 
>> URLStreamHandler already set by a containing application (e.g. servlet 
>> container). Once you've got your own URLStreamHandler and have worked 
>> around the VM's one, then you can just get on and solve the problems 
>> that you were working on, and we (Cocoon and others) can happily embed 
>> Felix within servlet containers, comfortable in the knowledge that we 
>> can enjoy all of the benefits of your work on URLStreamHandlers 
>> without any conflict with our container or any other apps running 
>> within it.
>> So, I think I'm aiming to solve a slightly different issue. Does it 
>> make more sense in the light of that?
> Yes, it makes sense and that is an important problem too, but that gets 
> us into other difficulties because we (from a Felix perspective) cannot 
> assume that we control the class loader that loads the hosting 
> application. This sounds like it would have to be integrated into a 
> generic launcher utility of some sort.


I was working under the impression (potentially mistaken) that you ask a 
classloader for a class, and that classloader defers to its parent, and 
if its parent doesn't find the class it looks for it in its own 
classpath. (This understanding comes from some limited work with the 
AntClassLoader). In this case, you could intercept the request before 
you defer to the System/Parent classloader. Are you saying that that 
_couldn't_ work?

Regards, Upayavira

View raw message