Richard S. Hall wrote:
Upayavira wrote:
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?
Well, I have certainly had worse ideas, but I am not sure if we should
us this approach. And ultimately, I don't think it solves the issue. We
are in a situation where we have a single stream of requests for
protocol handlers that must be multiplexed out to the appropriated
framework instance to be serviced. The above approach doesn't really
help with the multiplexing aspect.
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?
Regards, Upayavira
