tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kirk Rasmussen <>
Subject RE: Some questions (Servlet Init, common libraries, and controlli ng standard out/err)
Date Thu, 28 Sep 2000 20:50:52 GMT
Thanks for the response.  

I understand what you are saying.  The only thing that I disagree with is
that catching a run-time exception like ClassNotFoundException or
NullPointerException in a servlet or normal application code is in most
cases "A Bad Thing(TM)".  That exception should have bubbled up from my
servlet to the ContextManager at some point.  It should have at least
captured a stack trace and put the results in the log.  WebLogic does this
currently.  It makes problem solving much much easier if you have some idea
what went wrong.


ps I did mean Tomcat 3.2 beta 4.

-----Original Message-----
From: Craig R. McClanahan []
Sent: Thursday, September 28, 2000 1:41 PM
Subject: Re: Some questions (Servlet Init, common libraries, and
controlling standard out/err)

Kirk Rasmussen wrote:

> Hi,
> I have a several questions about Tomcat 3.4.

Err, 3.2beta4 right?

> 1a) I was trying to deploy a servlet that has many dependencies on other
> classes (e.g. TOPLink, JDBC drivers)  using the WAR method of deployment.
> When it failed to load because of a missing JAR I got no error messages in
> the logs at all.  Only when I tried to access the servlet from the browser
> did I get an internal error message with no information (very generic 500
> message).  I have the debug level set to 9 for all components.  What I
> have liked to see would be a stack trace showing me the class it was
> to load when it failed.  Any way to do this with Tomcat 3.2 beta 4?

The first thing to remember is that Java is a language that loads classes on
demand, the first time you reference them.  The fact that your servlet
references a class "Foo", and "Foo" isn't included in the WAR file anywhere,
not going to stop you from deploying the webapp.  You only run into a
when your servlet actually tries to use the offending class.

This leads to the second thing to remember -- it is your *servlet*, not
that tries to use the offending class.  Therefore, it is your servlet's
responsibility to handle this case appropriately.  One useful mechanism is
use the ServletContext.log() method that takes two arguments -- a message
and an exception -- which will cause the message and the stack trace to be
written to the server's log files (in directory $TOMCAT_HOME/logs for

For example:

    Foo foo = null;
    try {
        foo = new Foo();
    } catch (ClassNotFoundException e) {
        getServletContext().log("Cannot find Foo", e);

> 1b) Other than using symlinks under UNIX or changing the Java system
> classpath is there a way to share JARs across multiple webapps?  For
> we have multiple webapps that share the same JDBC drivers. It seems like a
> waste to have to copy that JDBC driver to each lib directory.

The rules for this are specific to each server.  With Tomcat, the way to do
is put the shared JAR files in the $TOMCAT_HOME/lib directory before
Tomcat.  You should note, however, that some Java classes will not behave
correctly when shared in this manner if they try to reference classes that
found only in the WEB-INF/classes or WEB-INF/lib directories.

> 1c) Can I put subdirs under WEB-INF/lib to organize the JARs in some way?

No -- only the JAR files at the top level are supposed to be loaded (some
versions of Tomcat actually did scan subdirectories, but this is a bug and
not portable to any other server).

> 2) Is there a way to control where standard out/err are sent other than
> the shell?

Assuming you are not running under a security manager that disables this,
can use System.setOut() and System.setErr() for this.  But servlet
should really be writing things to the servlet context logs (as illustrated

> Thanks,
> Kirk

Craig McClanahan

See you at ApacheCon Europe <>!
Session VS01 (23-Oct 13h00-17h00):  Sun Technical Briefing
Session T06  (24-Oct 14h00-15h00):  Migrating Apache JServ
                                    Applications to Tomcat

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message