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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
