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 Fri, 15 Aug 2008 14:40:02 GMT
> In brief, following steps are performed:
> 1. Class from my block is loaded using ResourceStoreClassLoader.  
> Let's call this class MAIN.
> 2. This class accesses some static method of another class loaded by  
> ResourceStoreClassLoader (because this class comes from my block as  
> well) and sets some value on static field. Let's call this class  
> STATIC

Just a quick comment: static + classloader == evil ;-)

> 3. Then another class (3RDPARTY) is being loaded which is not part  
> of my block, it's from third-party jar. It's loaded by parent  
> classloader to ResourceStoreClassLoader. As part of configuration of  
> this class I pass a name of class which is some kind of extension  
> point and is implemented by class coming from my block; let's call  
> this class EXTENSION.
> 4. 3RDPARTY creates new instance of EXTENSION class (and this class  
> is again not loaded by ResourceStoreClassLoader but by parent), but  
> in EXTENSION class one tries to access field set in STATIC.
> 5. While EXTENSION tries to access STATIC, STATIC is being loaded  
> again, using parent classloader. The value in STATIC is gone,  
> obviously.
>
> So the basic problem is that, this STATIC class is loaded by two  
> different classloaders.
>
> I'm wondering if there is any kind of general solution to such  
> problems. The only one I can think of is to enforce loading of  
> 3RDPARTY class by ResourceStoreClassLoader so everything stays  
> within one classloader and even reflection tricks are not dangerous.

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.

I would take a step back and re-think the situation. This static stuff  
smells like wants to be replaced ;-)

> However, that would mean that one needs to modify commons-jci project.

Why? How?

cheers
--
Torsten

Mime
View raw message