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
