tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Naresh Bhatia" <NBha...@sapient.com>
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 [mailto:funkman@joedog.org] 
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 log4j.properties anc drop it in WEB-INF/classes and
each 
webapp gets its own loggin config. (Disclaimer: I haven't extensively
used 
this yet but thats what the log4j docs say, but then again - I am making
a 
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
be 
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
are 
depending on a (relative) directory structure, you can just populate a
String 
value in your JNDI namespace which would just be String value that is
the 
name of a directory path to the root of your relative repository. Of
course 
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
own 
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.

-Tim



---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Mime
View raw message