You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@anyware-tech.com> on 2004/12/30 11:02:02 UTC
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
cziegeler@apache.org wrote:
>Author: cziegeler
>Date: Thu Dec 30 01:22:00 2004
>New Revision: 123708
>
>URL: http://svn.apache.org/viewcvs?view=rev&rev=123708
>Log:
>Remove unused classloader
>
>
<snip/>
> try {
>- final Class componentClass = this.loader.loadClass( info.getServiceClassName() );
>+ final Class componentClass = this.getClass().getClassLoader().loadClass( info.getServiceClassName() );
>
>
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.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Error in Cocoon 2.1.6 portal block example
Posted by javascript <ja...@tin.it>.
I've downloaded Cocoon 2.1.6 and made it with Ant but the Portal Block
Example is not displayed for this error:
org.apache.cocoon.ResourceNotFoundException: Resource not found.:
org.apache.excalibur.source.SourceNotFoundException:
file:/H:/eclipse/eclipse/workspace/cocoon2/build/webapp/samples/blocks/portal/coplets/console/sitemap.xmap
doesn't exist.
I should remade it or not? The directory "console" does not exist.
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.298 / Virus Database: 265.6.6 - Release Date: 28/12/2004
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
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
>
> 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().
>
Ah, yes, true - why didn't I see this? Hmpf :)
I'm currently refactoring the ECM++ a little bit; when that's finished
everything will run as beautiful as before ;)
Carsten
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
Posted by Sylvain Wallez <sy...@apache.org>.
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.
>
Thanks!
> 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
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
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
Posted by Carsten Ziegeler <cz...@apache.org>.
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...
Carsten
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
Posted by Carsten Ziegeler <cz...@apache.org>.
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.
Carsten
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
Posted by Sylvain Wallez <sy...@apache.org>.
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
contextCL!!!
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
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
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
Posted by Carsten Ziegeler <cz...@apache.org>.
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.
As soon as we need improved classloading we can do it the right way.
Or did I oversee something?
Carsten