Carl Rosenberger wrote:
>
> > > > When adding c:\java\my-web-app-dir\web-inf\classes to CLASSPATH
> > > > Tomcat is loosing the jars in my c:\java\my-web-app-dir\web-inf\lib
> > >
> > > Two workarounds were possible:
> > > - ..\project-dir\web-inf\classes added to the CLASSPATH
> > > - placing all Jars in ..\project-dir\web-inf\lib
> > >
> >
> > Isn't this due to how the classloaders work in a servlet container?
> > Classloaders in Servlet 2.2 spec containers don't look down for classes,
> > they look 'up'. So a class in WEB-INF/lib won't be found by a class
> > instantiated in an upper level loader.
>
> Thanks for explaining how servlet classloaders work.
That's just a sketch. I am not an expert :)
>
> Do you have more information on the reason for this beviour? Why not use one
> single classloader to be responsible for all levels? Is this a performance
> issue? Would it take the classloader too long to scan all paths in all
> directories for all possible classes that might be needed to work together?
> In this case some intelligent caching could do the trick.
The reason is that you want to be able to partition your applications in
the servlet runner, to avoid classname clashes (each webapp can have
their own classes w/o worrying if another webapp uses the same
classname). It also means that support packages, like jdbc drivers and
other utilities your webapp may use can be upgraded or changed for one
webapp w/o affecting any others.
That's why I keep everying I possibly can in WEB-INF/lib - along with
the ability to jar up the webapp for easy deployment, I know I am safe
from changes to the CLASSPATH or other webapps.
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
You have a genius for suggesting things I've come a cropper with!
