Sylvain Wallez wrote: >>For reloading: when the sitemap is reloaded, the classloader could only >>reload those classes/jars that have changed since the last load/reload. >> >> > > > Yes, but the classloader is created as part of the TreeProcessor build > process and therefore it's an all or nothing operation. Ah, ok.
> Smarter > reloading would mean transmitting the classloader from the current > processor to the newly created one, checking that the classpath > definition hasn't changed and crawling the classpath in search for changes. > > Not impossible, but a bit complicated and it won't fully solve the > ClassCastException problem for session attributes instance of reloaded > classes, although it will reduce the associated annoyances by reducing > the number of reloaded classes. > > Problem also is that keeping unchanged classes means keeping their > classloader and that therefore we need the classloader for reloaded > class to be a child of the previous one, thus creating a classloader > chain that will grow over time. Maybe that will impact memory and > performance. Ah, I see, hmm, sounds complicated. How does this new class loader searches for classes? Does it first ask the parent class loader? I'm just curious if it's save to put third party libraries into WEB-INF/lib *and* add them to a sitemap classpath. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
