tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kitching Simon <>
Subject RE: Servlet error I can't seem to resolve
Date Wed, 27 Dec 2000 17:50:27 GMT

> -----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 :-)


> 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 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
> > 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
> >
> org.apache.tomcat.core.ServletWrapper.handleRequest(
> > 9)
> >  at
> > org.apache.tomcat.core.ContextManager.service(
> >  at
> >
> org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(Htt
> >
> >  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 even
> > if its not a servlet. If so, do I list it as if it were a servlet?
> >
> > Thanks,
> > Brad Siegfreid
> > Iridiumdesign

View raw message