Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (athena.apache.org: domain of grek@tuffmail.com designates
 216.86.168.178 as permitted sender)
Message-ID: <48A59E0D.8080108@tuffmail.com>
Date: Fri, 15 Aug 2008 17:17:33 +0200
From: Grzegorz Kossakowski <grek@tuffmail.com>
User-Agent: Thunderbird 2.0.0.12 (X11/20071114)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: RCL plug-in and different classloaders issues
References: <48A58C71.5030207@tuffmail.com>
 <AEAC986D-6956-4444-9026-B884E40DFFE8@apache.org>
In-Reply-To: <AEAC986D-6956-4444-9026-B884E40DFFE8@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Torsten Curdt pisze:
> 
> Just a quick comment: static + classloader == evil ;-)

:-)

Yes, I thought the same but is there any other solution in scenario I outlined when it's thirdparty 
class that creates a new instance of your class, which in turn needs to access some of your resources?

>> 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.

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?

> 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?

>> 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...

-- 
Grzegorz Kossakowski