cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rice Yeh" <rice...@gmail.com>
Subject Re: ClassCastException becuase of different classloaders for a bean weaving by springframework
Date Thu, 28 Sep 2006 14:43:49 GMT
It does make a big difference. loadClass(name, false) in DefaultClassLoader
uses child-first loading strategy but loadClass(name, false) in ClassLoader
uses parent-first loading strategy. Then, when an instance of
DefaultClassLoader calls its paren's loadClass(name, false) and this parent
is alos an instance of DefaultClassLoader, the old code will load the class
from the top classloader (like AppClassLoader loading class from classpath).
But with the patch, the class will be loaded from the jars in
WEB-INF/cocoon/lib. This happens when using reloading classloader whose
parent is also a DefaultClassLoader.

Rice

On 9/28/06, Carsten Ziegeler <cziegeler@apache.org> wrote:
>
> Carsten Ziegeler wrote
> > So if your patch changes the behaviour, then we should perhaps overwrite
> > loadClass(String) as well and restore the default behaviour. So instead
> > of your patch, we just add a
> >
> > public Class loadClass(String name) throws CNFE {
> >     return this.loadClass(name, false);
> > }
> >
> > to the DefaultClassLoader class.
> Forget my idea from above :) In the case of the DefaultClassLoader class
> the loadClass
> is of course not overwritten and the above functionality is inherited
> from the ClassLoader class. So I can't see that your patch makes any
> difference.
>
> Carsten
> --
> Carsten Ziegeler - Open Source Group, S&N AG
> http://www.s-und-n.de
> http://www.osoco.org/weblogs/rael/
>
>
>

Mime
View raw message