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 Fri, 31 Dec 2004 11:16:35 GMT
Carsten Ziegeler wrote:

> Carsten Ziegeler wrote:
>> Sylvain Wallez wrote:
>>> 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 contextCL!!!
>> True.
>> Ok, I will readd the classloading stuff asap.


> Ah, now my memory comes back - actually I started with these changes in
> November before my vacation...ok, we had more than one place in ECM++
> where instances where created. I wanted to reduce this to one single
> place, which means first cleaning up class loading, redesigning to
> have one single place and then readding class loading. Gosh, it's
> been a so long time...


Actually, we currently don't need to specify a particular classloader as 
a constructor argument, but mostly need to use 
Thread.getCL().loadClass() instead of this.getClass().getCL().loadClass().


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

View raw message