tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeffry Guttadauro <jeff.guttada...@abbott.com>
Subject RE: Servlet error I can't seem to resolve
Date Wed, 27 Dec 2000 18:13:23 GMT
2 cents??  I'd say that was at least a buck fifty...  Good points all.  Very
enlightening.  Thanks for the explanation!





Simon.Kitching@orange.ch on 12/27/2000 11:51:53 AM
Please respond to tomcat-user@jakarta.apache.org
To: tomcat-user@jakarta.apache.org
cc:
Subject: RE: Servlet error I can't seem to resolve



> -----Original Message-----
> From: Jeffry Guttadauro [SMTP:jeff.guttadauro@abbott.com]
> Sent: Wednesday, December 27, 2000 6:07 PM
> To: tomcat-user@jakarta.apache.org
> 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


> Simon.Kitching@orange.ch on 12/27/2000 10:32:34 AM
> Please respond to tomcat-user@jakarta.apache.org
> To: tomcat-user@jakarta.apache.org
> 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:brad@iridiumdesign.com]
> > Sent: Wednesday, December 27, 2000 5:21 PM
> > To: tomcat-user@jakarta.apache.org
> > 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
>
>
>




Mime
View raw message