I also thought about that. I believe you would have to override the system classloader by specifying the java.system.class.loader property at jvm startup, but I am not sure. A method like this may be able to solve the problem for all instances trying to set these singletons, not just OSGi-implemented ones (e.g., a parent servlet container).
Jeremy On 10/3/05, Upayavira <[EMAIL PROTECTED]> wrote: > Richard S. Hall wrote: > > Niclas Hedhman wrote: > > > >> At the end of the day, the contract to be fulfilled lies in the > >> URLStreamHandler and its factory. You are expected to subclass the > >> URLStreamHandler and override a bunch of methods, like > >> openConnection(), parseURL() and toExternalForm(). The real problem > >> has nothing much to do with OSGi. It just try to provide a mechanism > >> to overcome the JVM/JDK limitations in a colaboration friendly manner. > >> > > > > Exactly. URL handling was implemented under the assumption that it would > > be controlled and used by a single application. The OSGi framework > > provides a collaborative environment for independent third parties. This > > in and of itself would still be okay with the URL Handlers service spec, > > but now we want to throw into the mix having multiple OSGi framework > > instances, which conceptually each have their own URL Handlers service. > > I don't know if this is a completely stupid idea, but... > > If we've got our own classloader, then requests for classes will be > passed to that for resolution. Hence, if a request for java.net.URL is > made, such that the URL.setURLStreamHandlerFactory() method can be > called, could we not, instead of returning a java.net.URL class, return > a proxy class that has an alternative implementation of > setURLStreamHandlerFactory()? That way we just route around the JVM > problem within our own classloader. > > Reasonable? Stupid? > > Upayavira >
