cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: [2.2] Support for per sitemap classloading?
Date Sun, 05 Mar 2006 13:19:59 GMT
Carsten Ziegeler wrote:
> Reinhard Poetz wrote:
>>Carsten Ziegeler wrote:
>>>One remaining question: currently we have several places where the
>>>thread context classloader is used (for example to create new
>>>instances). I guess that with the blocks-fw in place that the thread
>>>context class loader is not the correct one.
>>why do you think so? (just curious, I haven't had the idea yet that this could 
>>be a problem)
> Blocks provide isolated class loading, so every block has it's own class
> loader. Now, unless you want to change the thread context class loader
> on each method invokation between blocks (like we currently do for the
> environment stack with internal pipeline calls), then the thread context
> class loader is rarely the class loader for the "current" block.
> We currently use the thread context class loader to get "cocoon's
> classloader" which might be different (in 2.1.x) to the webapp class loader.

IIUC the classloading as you describe it here isn't in place, right? Currently 
we have one global classloader for *all* blocks (see the BlocksManager). The 
build system (= Maven 2) takes care that only one version of each artifact is 
added to the global classloader.

This will change with the introduction of the OSGi-based blocks-fw. Then OSGi 
will take care of it and that's the reason why we should wait before we come up 
with our own solutions (which hopefully won't be ncessary).

Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}



Telefonate ohne weitere Kosten vom PC zum PC:

View raw message