André Warnier wrote:
Konstantin Kolinko wrote:
2012/6/10 André Warnier <a...@ice-sa.com>:
No tomcat 5.5 files have been copied to that system (apart from the
webapp).
Here is the complete (edited, comments removed) content of
tomcat6/conf/catalina.properties :
(...)
common.loader=${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar,/var/lib/tomcat6/common/classes,/var/lib/tomcat6/common/*.jar
server.loader=${catalina.home}/server/classes,${catalina.home}/server/*.jar,/var/lib/tomcat6/server/classes,/var/lib/tomcat6/server/*.jar
shared.loader=${catalina.home}/shared/classes,${catalina.home}/shared/*.jar,/var/lib/tomcat6/shared/classes,/var/lib/tomcat6/shared/*.jar
The above fragment of catalina.properties explains the issue that you
are observing.
The "common.loader", "server.loader" and "shared.loader" values
provide configuration for Common, Server and Shared classloader, as
better documented in 5.5 (Tomcat 6 docs not mention Server and Shared
ones, but they still do exist):
http://tomcat.apache.org/tomcat-5.5-doc/class-loader-howto.html#Overview
If you look at a fresh copy of Tomcat 6, the values would be:
[[[
common.loader=${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar
server.loader=
shared.loader=
]]]
The ones that you have in your file are a mix of 5.5 and 6.0 values.
ClassLoaderFactory.validateFile() method is called in turn for each
value in each of the 3 *.loader options and checks that those values
point to an existing place, which is a directory and is readable.
In your case,
WARNING: Problem with directory [/usr/share/tomcat6/server/classes],
exists: [false], isDirectory: [false], canRead: [false]
it looked for [/usr/share/tomcat6/server/classes] and warned you that
the said directory does not exist.
Thank you Konstantin for this very thorough explanation.
So, it looks like my options to make the warnings disappear are
- either just create these directories (empty) in CATALINA_HOME
- or modify the tomcat6/conf/catalina.properties file to remove (direct
or indirect) references to /usr/share/tomcat6/server
As it is now, the file comes from the Tomcat 6 Debian package; I did not
modify that file.
I would imagine that if the Debian package maintainer decided to modify
the standard file, he had some reason to do that.
Based on your knowledge, do you have an idea as to why the Debian Tomcat
6 package maintainer may have considered it a good idea to modify the
standard catalina.properties in the way that he did ? Could it be to
make upgrades tomcat 5.5 -> tomcat 6 easier ?
(To me, there seems to be a curious mixture of "symbolic"
(${catalina.home}/*) and "hardwired" (/var/lib/tomcat6/*) references in
the Debian version of that file.)
For the record : adding the missing directories under CATALINA_HOME (/usr/share/tomcat6
here), and making them owned/readable by the tomcat6 user, definitely does it (make the
WARNING messages disappear) :
Jun 10, 2012 5:03:47 PM org.apache.coyote.http11.Http11Protocol pause
INFO: Pausing Coyote HTTP/1.1 on http-8080
Jun 10, 2012 5:03:48 PM org.apache.catalina.core.StandardService stop
INFO: Stopping service Catalina
Jun 10, 2012 5:03:49 PM org.apache.coyote.http11.Http11Protocol destroy
INFO: Stopping Coyote HTTP/1.1 on http-8080
Jun 10, 2012 5:03:57 PM org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on http-8080
Jun 10, 2012 5:03:57 PM org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 408 ms
Jun 10, 2012 5:03:57 PM org.apache.catalina.core.StandardService start
INFO: Starting service Catalina
Jun 10, 2012 5:03:57 PM org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.35
Jun 10, 2012 5:03:57 PM org.apache.catalina.startup.HostConfig deployDescriptor
INFO: Deploying configuration descriptor myapp.xml
...
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
