Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
From: bugzilla@apache.org
To: tomcat-dev@jakarta.apache.org
Subject: DO NOT REPLY [Bug 40220]  - Order of jar loading affects packaged
 resources
In-Reply-To: <bug-40220-78@http.issues.apache.org/bugzilla/>
Message-Id: <20061227101513.F084D7142B6@brutus.apache.org>
Date: Wed, 27 Dec 2006 02:15:13 -0800 (PST)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=40220>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=40220


------- Additional Comments From darryl@darrylmiles.org  2006-12-27 02:15 -------
The issue is straight forward and understood, I've come across it before and
unfortunately dont have anything concrete to point at to indicate which
behaviour is correct.


The question that remains "Is it legal to have the same package existing in more
than one source location on the classpath ?"

If the specification is clear that all class loaders MUST perform an exhaustive
search from all source locations.  Then TCs current behaviour is wrong and needs
to be fixed.

Anything less than a "MUST" allows TC to consider current behaviour correct.


Just thinking about this issue for a moment:

 * There maybe some securiry reasons why; when one one or more artifacts of a
package are found on the classpath then it will look no more.  This might stop a
rouge application adding classes into java.util.* package and possibily picking
up wildcard security policy for java.util.*.  Especially in the case of Java Web
Start / Applets, where one source location is the local JVM and another a remote
JAR on the webserver.

 * There are also performance reasons why its not the default, if you are doing
resource lookups and keep missing (resource not found), you are forcing a
complete classpath search everytime.

 * I'd expect the behaviour of generic Java custom class loader may leave this
policy open to allow things to go either way once the lookup has been delegated
away from the system class loader (to ensure java.util.* security).


My belief is that current behaviour can be considered correct.  But if TC wanted
to it could perform an exhaustive search within the web-app realm
WEB-INF/{classes,lib} if it so wished to implement such a class loading policy.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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