Richard S. Hall wrote:
Upayavira wrote:
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?
Yes, it makes sense and that is an important problem too, but that gets
us into other difficulties because we (from a Felix perspective) cannot
assume that we control the class loader that loads the hosting
application. This sounds like it would have to be integrated into a
generic launcher utility of some sort.
Interesting.
I was working under the impression (potentially mistaken) that you ask a
classloader for a class, and that classloader defers to its parent, and
if its parent doesn't find the class it looks for it in its own
classpath. (This understanding comes from some limited work with the
AntClassLoader). In this case, you could intercept the request before
you defer to the System/Parent classloader. Are you saying that that
_couldn't_ work?
Regards, Upayavira
