tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amos Shapira <amos.shap...@webcollage.com>
Subject RE: /lib & /WEB-INF/lib
Date Mon, 11 Jun 2001 04:54:41 GMT
Hi,

There is also the matter of whether you want the code (and data) to
be shared among the web apps or not.

For instance, we have a base servlet class which holds some static
variables which are ment to be used as "application-wide" variables
(e.g. logging configuration), and two web applications.

If that servlet class was in the shared library then the static variables
would have been shared among the applications as well, but we don't
want that so we put it under the application's WEB-INF/class directory,
like the rest of the code.

On the other hand, due to a bug in JDK 1.2.2, JNI classes cannot be
loaded by "custom class loaders" (hope I remember the right term), so
we HAD to put our JNI file locking class under the shared directory.

This (putting the JNI file locking class under a shared directory) also
solved
another problem - we actually WANTED to share the list of locked files
under Solaris since Solaris locks a file per-process (i.e. per the iPlanet
process under which the servlet engine runs) so we have to manage a
list of the files locked by that process - and so we wanted a single list
accessed from ALL our web applications.

As for how this works, I'm not completly into this, but a couple of points:

1. A class is identified by its full name but also by the class loader which
loaded
   it. When the application-specific class loader loads a function from
under
   WEB-INF, that class belongs to that class loader alone and classes loaded
by
   other class loaders simply do not see it (I guess because the JVM looks
up the
   class by name AND by the class loader of the other web app), that's also
why you
   might sometimes get "class cast exception" after replacing a class
without completly
   reloading an application, since a new class loader might be used to load
it. (maybe
   there is a matter of class loader hierarchy here too, so shared classpath
components
   are still seen as shared by all web apps).

2. Lookup material about class loaders to fully understand this.

Cheers,

--Amos

-----Original Message-----
From: Hemant Singh [mailto:hemant111in@yahoo.com]
Sent: Thursday, February 10, 2000 4:27 PM
To: tomcat-user@jakarta.apache.org
Subject: Re: /lib & /WEB-INF/lib


HI:
If you have a jar which you are using in more than  one web-apps than place
it under
/tomat/lib
so that tomcat do not reload the same jar more than once(I really surprise
how internally it works)

and if you are using that jar only in one web-app than place than place it
under
/tomcat/webappps/yourwebapp/web-inf/lib

Regards
Hemant
----- Original Message -----
From: "Bo Xu" <bo@cybershop.ca>
To: <tomcat-user@jakarta.apache.org>
Sent: Friday, June 08, 2001 7:02 PM
Subject: Re: /lib & /WEB-INF/lib


> eric ng wrote:
>
>
> > Hi,
> > In tomcat or other servlet engine implements the spec.
> >  there are 2 place to put JAR files:
> >
> > 1) d:/tomcat/lib
> > 2) d:/tomcat/webapps/abc/WEB-INF/lib
> >
> > I wonder what's the difference putting JAR in the 2
> > directory? any performance difference? Should I always
> > put JAR into web apps's own lib?
> >
> > thanks.
> > [...]
>
> Hi :-)
>
> - the jar files in TOMCAT_HOME/sebapps/myapp/WEB-INFlib
>   are loaded by the classloader of this webapp(myapp), normally they
>   are only used in this webapp(myapp).
>
> - the jar files in TOMCAT_HOME/lib are loaded by another classloader
>    (SharedClassloader) which is "upper" than the classloader of this
> webapp
>    or that webapp in "JAVA2 delegation model", these jar files are
> "shared"
>    for all webapp(0) or webapp(1) or webapp(2)...
>       % If you want to share a utility class to all webapp, you can wrap
>
>            it into a jar file, and put the jar file here.
>       % because sometimes the classloader of one special webapp(for
> example,
>            myapp) will be destroyed(for example, auto-reloading), so If
> you don't
>            want a utility class to be load/reload several times, you can
> wrap
>            it into a jar file, and put the jar file here.
>
>
> Bo
> June.08, 2001
>

Mime
View raw message