Re: Tomcat 5.5 classloading blues
Everything ran great. I got Tapestry examples working fine. And then based on working web apps, I moved some of the Tapestry jars into shared/lib. All of a sudden the classloader couldn't find ServletInputStream. That's a bit bizarre Exactly my point. I know that if you have multiple servlet-api.jars in the class path you get that sort of error, so I verified about a hundred times that I hadn't, and then decided to get some better logging output to figure out what went wrong. Then I realised that I needed to install commons logging and log4j to get proper logging, so I put them in commons as described. Now I get a NoClassDefFound on LogFactory instead. Did you put commons-logging.jar (*not* commons-logging-api.jar) along with logj4-jar in common/lib? And did you make sure you webapp doesn't contain another copy of commons-logging.jar in WEB-INF/lib? Yes I moved commons-logging-1.0.4.jar into the commons/lib along with log4j-1.2.8, and renamed to WEB-INF/lib to no-lib (Shouldnt be needing anything really) 1) The logging guide advises to put the jars in commons, why not put them in server/lib and in the invidual WEB-INF/lib to get per webapp log files and no risk of classloading issues ? First, this assumes that the server applies child-first classloading behavior which is recommended by the servlet spec, but not mandated. Tomcat implements this, and I actually like that it does, but most other servers I know of either don't provide for it or provide it as a non-default option. This means that putting your logging jars in WEB-INF/lib does not guarantee per-webapp log files unless you stick to Tomcat. This can be better accomplished by using a repository selector in Log4j (especially when Log4j-1.3 is released as it makes usage of such selectors much easier). http://wiki.apache.org/logging-log4j/AppContainerLogging Well, I just wondered why the Tomcat docs were not at least explaining such considerations. Others have warned against the repository selector until 1.3 comes out. And I'm sure that I am not the only one who would want seperate logging facilities working painlessly in their current environment. Thanks for the input, Henrik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5 classloading blues
Hello, I'm new to the list and did not read this thread from the beginning but also use tapestry (3.0) on tomcat. I keep tapestry-3.0.jar and tapestry-contrib-3.0.jar in the lib dir of the (to be deployed) war file, the rest goes to /shared/lib except xercesImpl.jar and xml-apis.jar which go in /common/endorsed (very special case) The classloading problem I ran into was on the dbms side, jdbc drivers should go into /common/lib if you want to use pooling because the dbcp stuff resides here. The class.forName() call is mostly the reason for these troubles because it relies on the current classloader ... Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5 classloading blues
Quoting Andreas Vombach [EMAIL PROTECTED]: Hello, I'm new to the list and did not read this thread from the beginning but also use tapestry (3.0) on tomcat. I keep tapestry-3.0.jar and tapestry-contrib-3.0.jar in the lib dir of the (to be deployed) war file, the rest goes to /shared/lib except xercesImpl.jar and xml-apis.jar which go in /common/endorsed (very special case) The classloading problem I ran into was on the dbms side, jdbc drivers should go into /common/lib if you want to use pooling because the dbcp stuff resides here. The class.forName() call is mostly the reason for these troubles because it relies on the current classloader ... Which is why you should always do.. Class.forName(com.mypackage.SomeClass, true, Thread.currentThread().getContextClassLoader()); Jake Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5 classloading blues
Yes, if you look into the commons-dbcp 1.2.1 source,
BasicDataSource.java, line 757 ff:
// Load the JDBC driver class
if (driverClassName != null) {
try {
Class.forName(driverClassName);
} catch (Throwable t) {
String message = Cannot load JDBC driver class ' +
driverClassName + ';
logWriter.println(message);
t.printStackTrace(logWriter);
throw new SQLNestedException(message, t);
}
}
I think this is the one being used in tomcat 5.5.4.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat 5.5 classloading blues
Still remembering earlier bruises setting up Tomcat I try to run as plain vanilla as possible. Fedora Core 3, Tomcat 5.5.4 Java 5 installed with rpm's Everything ran great. I got Tapestry examples working fine. And then based on working web apps, I moved some of the Tapestry jars into shared/lib. All of a sudden the classloader couldn't find ServletInputStream. Then I realised that I needed to install commons logging and log4j to get proper logging, so I put them in commons as described. Now I get a NoClassDefFound on LogFactory instead. 1) The logging guide advises to put the jars in commons, why not put them in server/lib and in the invidual WEB-INF/lib to get per webapp log files and no risk of classloading issues ? 2) Am I just stupid to attempt to use shared/lib rather than just sticking everything in the war file ? 3) Where can I find a list of the jar's present in server/lib commons/lib shared/lib in a fresh install ? 4) Is JMX tools to manage Tomcat the way forward ? Thanks for any comments, Henrik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5 classloading blues
On Mon, Dec 20, 2004 at 01:11:42AM -, Henrik Vendelbo wrote:
: Fedora Core 3, Tomcat 5.5.4 Java 5 installed with rpm's
Any reason you used RPMs instead of raw tarballs/zipfiles?
I usually prefer RPMs, don't get me wrong -- but when it comes to Java
apps, I find RPMs overkill and too much of a hassle.
: And then based on working web apps, I moved some of the Tapestry jars into
: shared/lib.
Any reason you did this?
In my experience, using /shared/lib was more trouble than it's worth.
Read on:
: 2) Am I just stupid to attempt to use shared/lib rather than just sticking
: everything in the war file ?
Stupid is a harsh term in this case; but it's certainly preferable
that each webapp be a standalone, portable unit.
Some people use shared/lib or common/lib in the hopes of saving space,
but I'd rather sacrafice a few mb here and there if it makes it easier
for me to shuffle my app around. -that, and using container-wide
repositories for app-level JARs is asking for a headache when
applications' needs diverge.
: 3) Where can I find a list of the jar's present in server/lib commons/lib
: shared/lib in a fresh install ?
If you used the RPM:
rpm -ql -p {RPM file} | egrep 'server/lib|common/lib'
or just grab the raw zip file:
unzip -l {RPM file} | egrep 'server/lib|common/lib'
: 4) Is JMX tools to manage Tomcat the way forward ?
I suppose this is more a question for the developers; but it really
depends on what you mean by manage. If you're not doing anything
fancy, then the basic start/stop scripts should be fine. ;)
-QM
--
software -- http://www.brandxdev.net
tech news -- http://www.RoarNetworX.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5 classloading blues
I agree.
Sometimes I encouter some displeasure when copy or move the jar files
to /shared/lib, which I thought should be nothing serious.
But I donot think RPMs could make installing Tomcat a mess.
And, indeed, just sticking everything in the war file is more portable :)
On Sun, 19 Dec 2004 20:25:58 -0600, QM [EMAIL PROTECTED] wrote:
On Mon, Dec 20, 2004 at 01:11:42AM -, Henrik Vendelbo wrote:
: Fedora Core 3, Tomcat 5.5.4 Java 5 installed with rpm's
Any reason you used RPMs instead of raw tarballs/zipfiles?
I usually prefer RPMs, don't get me wrong -- but when it comes to Java
apps, I find RPMs overkill and too much of a hassle.
: And then based on working web apps, I moved some of the Tapestry jars into
: shared/lib.
Any reason you did this?
In my experience, using /shared/lib was more trouble than it's worth.
Read on:
: 2) Am I just stupid to attempt to use shared/lib rather than just sticking
: everything in the war file ?
Stupid is a harsh term in this case; but it's certainly preferable
that each webapp be a standalone, portable unit.
Some people use shared/lib or common/lib in the hopes of saving space,
but I'd rather sacrafice a few mb here and there if it makes it easier
for me to shuffle my app around. -that, and using container-wide
repositories for app-level JARs is asking for a headache when
applications' needs diverge.
: 3) Where can I find a list of the jar's present in server/lib commons/lib
: shared/lib in a fresh install ?
If you used the RPM:
rpm -ql -p {RPM file} | egrep 'server/lib|common/lib'
or just grab the raw zip file:
unzip -l {RPM file} | egrep 'server/lib|common/lib'
: 4) Is JMX tools to manage Tomcat the way forward ?
I suppose this is more a question for the developers; but it really
depends on what you mean by manage. If you're not doing anything
fancy, then the basic start/stop scripts should be fine. ;)
-QM
--
software -- http://www.brandxdev.net
tech news -- http://www.RoarNetworX.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5 classloading blues
At 01:11 AM 12/20/2004 +, you wrote: Still remembering earlier bruises setting up Tomcat I try to run as plain vanilla as possible. Fedora Core 3, Tomcat 5.5.4 Java 5 installed with rpm's Everything ran great. I got Tapestry examples working fine. And then based on working web apps, I moved some of the Tapestry jars into shared/lib. All of a sudden the classloader couldn't find ServletInputStream. That's a bit bizarre Then I realised that I needed to install commons logging and log4j to get proper logging, so I put them in commons as described. Now I get a NoClassDefFound on LogFactory instead. Did you put commons-logging.jar (*not* commons-logging-api.jar) along with logj4-jar in common/lib? And did you make sure you webapp doesn't contain another copy of commons-logging.jar in WEB-INF/lib? 1) The logging guide advises to put the jars in commons, why not put them in server/lib and in the invidual WEB-INF/lib to get per webapp log files and no risk of classloading issues ? First, this assumes that the server applies child-first classloading behavior which is recommended by the servlet spec, but not mandated. Tomcat implements this, and I actually like that it does, but most other servers I know of either don't provide for it or provide it as a non-default option. This means that putting your logging jars in WEB-INF/lib does not guarantee per-webapp log files unless you stick to Tomcat. This can be better accomplished by using a repository selector in Log4j (especially when Log4j-1.3 is released as it makes usage of such selectors much easier). http://wiki.apache.org/logging-log4j/AppContainerLogging 2) Am I just stupid to attempt to use shared/lib rather than just sticking everything in the war file ? This is a nice little piece on the subject. I think you can extrapolate this to any framework or library, not just Struts... http://struts.apache.org/userGuide/configuration.html#config_add 3) Where can I find a list of the jar's present in server/lib commons/lib shared/lib in a fresh install ? Just grab a zipped or gzipped copy and look for yourself. Jake 4) Is JMX tools to manage Tomcat the way forward ? Thanks for any comments, Henrik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
