Peter Kriens wrote:
Depending on the overall architecture, the outer class loader could
load special, modified, classes for the URLStreamHandler class. I once
did something like for the System and Runtime classes. AOP!
Let me see if I am understanding you. Are you suggesting that Felix
could, whenever asked for a URLStreamHandler, instead of returning the
one that is provided by the JVM, it returns its own - doesn't go
anywhere near the JVM to get it?
Regards, Upayavira
Kind regards,
Peter Kriens
NH> On Wednesday 28 September 2005 17:38, Richard S. Hall wrote:
One thing is certain, though, is that we cannot come up with a solution
that will work for legacy apps that assume that they are the ones to
call the "set factory" method; code will have to be modified to use
whatever solution we come up with.
NH> Well, it also depends largely on how the existing owner of the URL/Content
NH> handler factory is organized.
NH> If ContainerX sets a stream handler factory, which only deals with its own
NH> problem domain, and does not provide an extension mechanism then that
NH> ContainerX must be modified to be supported.
NH> If ContainerY provides a extension mechanism, then we could create a
solution
NH> for ContainerY, without modifying ContainerY, thanks to the modularity of
NH> OSGi itself.
NH> I don't think it is likely that generic solutions for the short term will be
NH> feasible, mostly for political reasons.
NH> Cheers
NH> Niclas
