tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Naresh Bhatia" <>
Subject RE: Modifying Tomcat's classpath
Date Thu, 01 May 2003 12:27:34 GMT
Thanks Tim. Your comments make complete sense to me. Time to look at
JNDI :-).

-----Original Message-----
From: Tim Funk [] 
Sent: Thursday, May 01, 2003 7:56 AM
To: Tomcat Users List
Subject: Re: Modifying Tomcat's classpath

inline ...

Naresh Bhatia wrote:
> 1) I like to keep my log4j.xml configuration file common to all web 
> apps. In fact I would like Tomcat to be using log4j and my 
> configuration file (haven't found a way to do this yet).
You can also create anc drop it in WEB-INF/classes and
webapp gets its own loggin config. (Disclaimer: I haven't extensively
this yet but thats what the log4j docs say, but then again - I am making
massive shift to commons-logging)

> 2) I have a read/write "data" directory that I need several webapps to

> have access to, via the classpath - getResourceAsStream(). It does not

> feel right to put this data directory in WEB-INF/classes or 
> WEB-INF/lib.
Thats because it should not feel right. A better(?) way is to do this is

JNDI. That way, the JNDI environment can be setup in server.xml and can
altered by a sysadmin when your data directory needs moved. You can also

create your own JNDI factories (for any complexity you want) or if you
depending on a (relative) directory structure, you can just populate a
value in your JNDI namespace which would just be String value that is
name of a directory path to the root of your relative repository. Of
that being said - rewriting code to do this is a PITA if you already
have a 
working application.

The more classes you place "closer" to the system classloader, the
harder it 
becomes to make your system highly available and (more important)
stable. The 
multiple classloader scheme is meant to allow each webapp to have its
version of libraries so competing version of the same jar can peacefully

exist in a single JVM. And upgrades to libraries can be an isolated
event to 
a single webapp without introducing regression issues to other webapps.


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

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

View raw message