tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Brandt-Erichsen" <>
Subject Re: Servlet error I can't seem to resolve
Date Wed, 27 Dec 2000 21:10:00 GMT

Wow, more like a few dollars worth!
Thank you for your insights.

Would you be willing to share the
dir structure and the web.xml file for
one of your self-contained webapps?

This would be incredibly helpful!

Thanks again.

-----Original Message-----
From: Kitching Simon <>
To: '' <>
Date: Wednesday, December 27, 2000 9:51 AM
Subject: RE: Servlet error I can't seem to resolve

>> -----Original Message-----
>> From: Jeffry Guttadauro []
>> Sent: Wednesday, December 27, 2000 6:07 PM
>> To:
>> 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
>> on 12/27/2000 10:32:34 AM
>> Please respond to
>> To:
>> 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 []
>> > Sent: Wednesday, December 27, 2000 5:21 PM
>> > To:
>> > Subject: Servlet error I can't seem to resolve
>> >
>> > I have a simple form handling servlet (FormEngineLight) that connects
>> 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
>> > classes) is:
>> >
>> > java.lang.NullPointerException
>> >  at java.util.Hashtable.put(
>> >  at IridiumSendMail.sendIt(
>> >  at FormEngineLight.writeToIridiumSendMail(
>> >  at FormEngineLight.sendConfirmation(
>> >  at FormEngineLight.service(
>> >  at javax.servlet.http.HttpServlet.service(
>> >  at
>> >
>> > 9)
>> >  at
>> > org.apache.tomcat.core.ContextManager.service(
>> >  at
>> >
>> >
>> >  at
>> >
>> > 38)
>> >  at
>> >
>> > 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
>> > if its not a servlet. If so, do I list it as if it were a servlet?
>> >
>> > Thanks,
>> > Brad Siegfreid
>> > Iridiumdesign

View raw message