cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: svn commit: r123708 - in cocoon/trunk/src: core/java/org/apache/cocoon/core/container core/test/org/apache/cocoon/core/container java/org/apache/cocoon java/org/apache/cocoon/components/container java/org/apache/cocoon/components/treeprocessor/sitemap samples/org/apache/cocoon/samples/parentcm
Date Thu, 30 Dec 2004 23:27:19 GMT
Carsten Ziegeler wrote:

> Sylvain Wallez wrote:
>> Why? This seems very dangerous to me as it doesn't use the Thread's 
>> context classloader (or any other given classloader), and will cause 
>> problems if the jar containing this class is higher in the 
>> classloader tree than the loaded class. Think e.g. autocompling 
>> classloader or real blocks classloaders.
> The current classloading was a little bit confusing. Only the root 
> manager got the classloader set, everything else (sub managers, 
> selectors etc) not. For now - without blocks - we don't need this.
> The Cocoon class is instantiated using the configured class loader
> (Thread Context) and the cocoon class instantiates ECM++. So,
> ECM++ uses this class loader as well.

Nono! Loading a class using the Thread's contextCL doesn't mean that 
class is actually loaded by this CL: it just means that search starts at 
this CL and crawls up the CL tree. So ECM++ loads classes in the 
classloader it was loaded in, which can be an ancestor of the Thread's 

Hey Carsten, do you drink so much between Chrismas and New Year that you 
forget this basic classloading stuff?

> As soon as we need improved classloading we can do it the right way.
> Or did I oversee something?

Maybe this breaks the autocompiling classloader introduced recently by 
Torsten. Need to check...


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message