2 cents?? I'd say that was at least a buck fifty... Good points all. Very
enlightening. Thanks for the explanation!
[EMAIL PROTECTED] on 12/27/2000 11:51:53 AM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: RE: Servlet error I can't seem to resolve
> -----Original Message-----
> From: Jeffry Guttadauro [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, December 27, 2000 6:07 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Servlet error I can't seem to resolve
>
> Hi, Simon.
>
> Why would you say that it's a bad idea to put .jar files in the
> classpath? In the case of commonly-used jars, like mail.jar for example,
> why
> would it be better to replicate this in each application's WEB-INF/lib
> directory?
>
> Thanks,
> -Jeff
>
[Kitching Simon]
First of all, it makes it easier to install a webapp.
For example, if you migrate a webapp to a different
machine because it has been wildly successful and
bigger hardware is required, and all required libs are
under WEB-INF/lib, then the move is trivial. Otherwise,
the required libs need to be installed separately. And
remember that this may happen well after the original
developers have left!
Secondly, it removes inter-webapp version dependencies.
Suppose that one webapp requires an updated version of a
shared lib. If you upgrade the shared lib, then you need to
retest every single webapp, even if only one of them *actually*
needed the upgrade. And with libs in the classpath, it
can be difficult to even know which webapps use a lib
and which don't.
Thirdly, putting stuff in the classpath interferes with
auto-reloading of changed classes. Each webapp gets its
own classloader, which makes it possible to do things like
dynamically reloading classes that have changed, and
stopping a single webapp context without shutting down
the whole of tomcat. If some of the webapp's code is loaded
from the CLASSPATH (ie is loaded by the system classloader,
not the webapp-specific classloader) then there can
be problems.
Fourthly, when a class is loaded via the system classpath,
there is only one copy of the class methods, and one copy
of class (ie static) variables for that class. If methods on the
class are synchronized, then there will be contention for the
class lock between webapps. One webapp could possibly
hang another by acquiring & not releasing such a lock. When
a class is loaded by the webapp-specific classloader, this
contention cannot occur - webapps are better isolated from
each other. And of course, if a webapp sets the value of a
static member of the class (eg setMaxFoo(3)) then that
attribute is visible to all webapps in the tomcat instance,
again not providing web application isolation. (note, while
this could be regarded as a "feature" for allowing data
communication between webapps, I thing this is a bad
idea, as it assumes the webapps are running in the same
virtual machine. Communicating via a shared database,
or a shared EJB, or even raw sockets, seems to me to be
a better way for webapps to intercommunicate).
Fifthly, if you get seriously into security, for example by
defining java security policies, then there may
be implications. I'm not entirely sure about the effects
here, but it seems that having per-webapp copies
of libs, and *not* having extra stuff in the classpath
(eg libs used by other webapps) can only be good.
Sixthly, I think there are problems with loading resource
files. If you (or shared code) calls getResourceBundle()
or related methods, I suspect the places the JVM looks for
the resource file is different...
Against that, the "libs in CLASSPATH" approach seems to
offer two benefits: save disk space and save RAM. I think
trying to save a megabyte of disk space (and that's a big jar!)
is really pointless in this age. Saving RAM by only loading
one copy of a class might have some benefit - but I'm not
sure that this doesn't happen anyway. The fact that a class
needs to *behave* as if it were per-classloader doesn't mean
that two copies of the bytecode are loaded (or does it? I
don't know what run-time-linking does to the original bytecode...)
I guess if you have a really large jar, and dozens of webapps
use it, there is a valid case for the classpath approach, but
in general I think having self-contained webapps makes
life easier for everyone concerned..
Just my two cents :-)
Simon
> [EMAIL PROTECTED] on 12/27/2000 10:32:34 AM
> Please respond to [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> cc:
> Subject: RE: Servlet error I can't seem to resolve
>
> The stack-trace seems pretty clear to me - the
> "sendIt" method of the IridiumSendMail class is
> storing a null pointer into a hashtable.
>
> What you may find is that the IridiumSendMail
> class is expecting to load a resource file from
> somewhere, but not finding it because you
> forgot to install it, or didn't install it in the
> right place.
>
> Just a note on the location of the "mail.jar"
> and "activation.jar" files - I think that the
> correct place for these is where you
> first had them, in the WEB-INF/lib
> directory within your web application.
> Placing jars in the classpath is
> generally a bad idea with tomcat
> (though quite a lot of tomcat users
> don't seem to understand this; presumably
> they are the same ones that would be
> using global variables under c++ :-)
>
> regards,
>
> Simon
> > -----Original Message-----
> > From: Brad Siegfreid [SMTP:[EMAIL PROTECTED]]
> > Sent: Wednesday, December 27, 2000 5:21 PM
> > To: [EMAIL PROTECTED]
> > Subject: Servlet error I can't seem to resolve
> >
> > I have a simple form handling servlet (FormEngineLight) that connects to
> a
> > email class (IridiumSendMail) that have been working with another host
> > under JServ 1.0b3. I moved to a new host with Tomcat 3.2 and also now
> have
> > Tomcat 3.2 working on a local machine for testing. Now my servlet/class
> > combo fails to work in either location. They require mail.jar and
> > activation.jar, which are in the classpath (initially just in the
> context
> > lib directory, now in the locations that load at boot). My apps are
> > compiled agains Java 1.18 but are running on 1.2 for both local and
> > hosted.
> >
> > The stackTrace I get from FormEngineLight (emailed back using the
> > sun.net.smtp classes) is:
> >
> > java.lang.NullPointerException
> > at java.util.Hashtable.put(Hashtable.java:381)
> > at IridiumSendMail.sendIt(IridiumSendMail.java)
> > at FormEngineLight.writeToIridiumSendMail(FormEngineLight.java)
> > at FormEngineLight.sendConfirmation(FormEngineLight.java)
> > at FormEngineLight.service(FormEngineLight.java)
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> > at
> >
> org.apache.tomcat.core.ServletWrapper.handleRequest(ServletWrapper.java:49
> > 9)
> > at
> > org.apache.tomcat.core.ContextManager.service(ContextManager.java:559)
> > at
> >
> org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(Htt
> > pConnectionHandler.java:160)
> > at
> >
> org.apache.tomcat.service.TcpConnectionThread.run(SimpleTcpEndpoint.java:3
> > 38)
> > at java.lang.Thread.run(Thread.java:479)
> >
> > Both of my files are in jars and reside in the lib directory. The
> > FormEngineLight servlet is accessible and sends me the error shown
> above.
> > Does the IridiumSendMail file have to be listed in the web.xml file even
> > if its not a servlet. If so, do I list it as if it were a servlet?
> >
> > Thanks,
> > Brad Siegfreid
> > Iridiumdesign
>
>
>
