Bug 48863 - Log directory misconfiguration for class loaders
Summary: Log directory misconfiguration for class loaders
Alias: None
Product: Tomcat 6
Classification: Unclassified
Component: Catalina (show other bugs)
Version: unspecified
Hardware: All All
: P2 enhancement (vote)
Target Milestone: default
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2010-03-05 09:04 UTC by Ralf Hauser
Modified: 2011-06-03 08:02 UTC (History)
0 users

patchApacheTomcat48863.txt (1.23 KB, patch)
2010-03-05 15:37 UTC, Ralf Hauser
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ralf Hauser 2010-03-05 09:04:04 UTC
When developing our tomcat applications with eclipse, doing out-rebuild/sysdeo plugin and have the class files written into TOMCAT_HOME/common/classes is an effective approach.

For manageability reasons, we need to split our code among several eclipse projects. The problem is if both are configured to place their .class files in TOMCAT_HOME/common/classes that when one project rebuilds, it will wipe the class files of the other one.

A great efficiency gain for the development of multiple projects therefore would be to be able to specify additional classes folders in server.xml to be added to the corresponding class-loader
Comment 1 Rainer Jung 2010-03-05 09:12:46 UTC
Isn't that what you can already do using the loader entries in conf/catalina.properties?
Comment 2 Mark Thomas 2010-03-05 09:13:29 UTC
This is already supported. See the catalina.properties file.
Comment 3 Ralf Hauser 2010-03-05 14:13:11 UTC
unfortunately, the com.sysdeo.eclipse.tomcat_3.2.1 ignores this "common.loader" attribute of catalina.properties at least with tomcat 5.5
Comment 4 Ralf Hauser 2010-03-05 15:37:59 UTC
Created attachment 25088 [details]

oops, sysdeo works ;)

but a typo is not seen whatsoever

The attached patch helps users find such a configuration error.

1) re-open this bug
2) re-apply
3) consider even using std-out for this error
Comment 5 Ralf Hauser 2010-03-08 06:58:13 UTC
see also Bug 48870
Comment 6 Mark Thomas 2011-02-18 16:00:30 UTC
Thanks for the patch. I applied a variation to 7.0.x (will be in 7.0.9 onwards) and proposed it for 6.0.x
Comment 7 Konstantin Kolinko 2011-02-27 13:46:41 UTC
Regarding the patch that is applied to tc7 at r1073047 and is currently proposed for 6.0.x:

1) The calls to ClassLoaderFactory#validateFile(file, type) pass canonical path for DIR and JAR, but not for GLOB.  I mean, the following change to be done, for consistency: (in trunk)

Index: java/org/apache/catalina/startup/ClassLoaderFactory.java
--- java/org/apache/catalina/startup/ClassLoaderFactory.java	(revision 1075098)
+++ java/org/apache/catalina/startup/ClassLoaderFactory.java	(working copy)
@@ -187,6 +187,7 @@
                 } else if (repository.getType() == RepositoryType.GLOB) {
                     File directory=new File(repository.getLocation());
+                    directory = new File(directory.getCanonicalPath());
                     if (!validateFile(directory, RepositoryType.GLOB)) {

BTW, with the above change the calls to file.getAbsolutePath() inside of #validateFile() become unnecessary.

2) The following check in ClassLoaderFactory#validateFile(file, type) assumes that Bootstrap.getCatalinaBase() is an absolute (and canonical, because file is canonical) path. But that is not guaranteed to be so:

if (!Bootstrap.getCatalinaHome().equals(       
                Bootstrap.getCatalinaBase()) &&
                Bootstrap.getCatalinaBase())) {
Comment 8 Mark Thomas 2011-02-28 08:51:34 UTC
Thanks for the review. Patch updated in 7.0.x for 7.0.9 and proposal for 6.0.x also updated.
Comment 9 Mark Thomas 2011-06-03 08:02:05 UTC
Fixed in 6.0.x and will be in 6.0.33 onwards.