Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Message-ID: <5DDF144C9176D211BE8F00805FC1A0D30396279A@duro.lucasfilm.com>
From: Kirk Rasmussen <krasmussen@lucasfilm.com>
To: "'tomcat-dev@jakarta.apache.org'" <tomcat-dev@jakarta.apache.org>
Subject: RE: Some questions (Servlet Init, common libraries, and controlli
	ng  standard out/err)
Date: Thu, 28 Sep 2000 13:50:52 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"

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.

Thanks,
Kirk

ps I did mean Tomcat 3.2 beta 4.

-----Original Message-----
From: Craig R. McClanahan [mailto:Craig.McClanahan@eng.sun.com]
Sent: Thursday, September 28, 2000 1:41 PM
To: tomcat-dev@jakarta.apache.org
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
would
> have liked to see would be a stack trace showing me the class it was
trying
> 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,
is
not going to stop you from deploying the webapp.  You only run into a
problem
when your servlet actually tries to use the offending class.

This leads to the second thing to remember -- it is your *servlet*, not
Tomcat,
that tries to use the offending class.  Therefore, it is your servlet's
responsibility to handle this case appropriately.  One useful mechanism is
to
use the ServletContext.log() method that takes two arguments -- a message
string
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
Tomcat).

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
example
> 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
this
is put the shared JAR files in the $TOMCAT_HOME/lib directory before
starting
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
are
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
is
not portable to any other server).

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

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

>
> Thanks,
> Kirk
>

Craig McClanahan

====================
See you at ApacheCon Europe <http://www.apachecon.com>!
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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org