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 15:53:26 GMT
Yeah, you are right. I made it wrong. The DefaultClassLoader.loadClass(name,
false) will be invoked since overridden method has priority anyway.

Rice

On 9/28/06, Rice Yeh <riceyeh@gmail.com> wrote:
>
> 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