Well, if you think about it: with this setup there is no other way
around to have the parent classloader know of the static class to
have this problem resolved. As you can't (?) modify the parent
classloader your only chance is to have the EXTENSION loaded by the
RSCL as well.
But how this can be enforced? I mean, 3RDPARTY is loaded by parent
and 3RDPARTY, when tries to create a new instance of EXTENSION uses
it's own classloader thus uses parent. The only solution I can see
here is that I load 3RDPARTY using classloader coming from JCI so
then EXTENSION will be loaded with this classloader as well.
Am I missing something?
No, I was trying to say the same thing :)
I would take a step back and re-think the situation. This static
stuff smells like wants to be replaced ;-)
If I knew how to do it, I would go with that direction
immediately. :-P
:-)
Basically, the problem is that one wants to access Spring's
application context within EXTENSION's constructor. Any suggestion
how to do it without using static class?
Well, the only thing I could think of right now:
Define a common interface that is loaded by parent. Delegate to an
implementation of that from EXTENSION. That should work.
But if you want to extend something that is changing (and not has a
fix interface) you will have to load it from the RSCL.
However, that would mean that one needs to modify commons-jci
project.
Why? How?
I was thinking to enforce ResourceStoreClassLoader to load
everything but I know that it's not the best idea...
Well, the RCL currently is pointed to a folder of class files. It
should not be too hard to also have it monitor a directory of jars.
cheers
--
Torsten
