cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <tcu...@apache.org>
Subject Re: RCL plug-in and different classloaders issues
Date Sat, 16 Aug 2008 11:56:24 GMT
>> 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

Mime
View raw message