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 }
