Felix, You are right that separate class loaders and/or an already registered handler factory would cause difficulty for the current URL Handlers implementation.
There is actually a JIRA issue for latter issue (don't know the number...i am traveling). The idea was to implement the approach that Equinox uses to replace an existing factory using reflection. As for the former issue, it could be possible to modify the current approach to use reflection and use class name comparison instead of instanceof comparison. I would have to look at the code to see if it would really be possible, but I wonder if it is worth it right now. Do you have a need for it now or are you just wish listing? -> richard -----Original Message----- From: "Felix Meschberger" <[EMAIL PROTECTED]> Subj: Re: URL Handlers Service Date: Wed 1. Nov 2006 7:10 Size: 819 bytes To: felix-dev@incubator.apache.org Hi Karl, > Felix already does provide something like that. Have a look at: Yes, I know and this is great. But this (1) class is package private, hence not available from outside, and (2) if the Felix is instance sets the framework.service.urlhandlers property to false the URL handler support is disabled for that instance and (3) if the property is true, at least one URLHandlers instance is created which calls the URL.setURLStreamHandlerFactory() and URLConnection.setContentHandlerFactory() methods. This fails if either method has already been called. Consequently, I am back to the start: What if the factories have already been registered by a non-Felix application ? What if two Felix instances run in two separate class loader hierarchies, which means, they don't have access to each other ? Regards, Felix