https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #39 from Mark Thomas <ma...@apache.org> --- The more I think about this, the more convinced I am that the proposed patch, even with the ordering behaviour made optional via configuration, is not the right way to address this issue. The proposed approach (ordering the JARs alphabetically and then having Tomcat search them in order for classes) will not address the following issues: - There is no guarantee that test environments will use the same ordering. Tests may execute with one version of a class while production runs with a different version leading to issues being missed during testing. - When the Servlet pluggability requirements are considered things could get very messy, very quickly. The pluggability scan scans every JAR. It would be possible for an annotation to be found on one class during the scan only for that annotation to appear to be missing when Tomcat loaded the class. - Any use of the service loader mechanism would need to be wrapped/customized/etc to ensure the expected behaviour. The first two issues above are the issues I came up with while thinking about this for a few minutes and the third occurred to me while trying to write the conclusion to this post. I suspect there are other issues I haven't thought of. I accept that some applications won't be affected by the above issues and/or there are ways to work around the above issues. However, those workarounds are likely to be fragile. A complete solution in Tomcat would be relatively invasive. Looking at the annotation scanning code with this in mind, changes would be required - particularly to the recently added option to scan JARs in parallel. My concern with trying to make this an officially supported feature of Tomcat is that it will result in a steady stream of edge cases emerging which in turn would result in increasingly complex code - particularly around pluggability. I accept that this is a subjective view and that things might turn out differently but that is my best assessment based on the requirements expressed in this issue and my experiences working with the Tomcat code base. I continue to think that the best and right way to fix this issue is to fix the applications so they no longer include multiple versions of the same class in different JARs in WEB-INF/lib. For those users who prefer to modify Tomcat's behaviour, I'm happy to work on making it easier to provide custom WebResource implementations and to replace selected components of Tomcat's default WebResource implementation (so it would be easy to drop in a custom DirResourceSet that provided the behaviour in the attached patch for example). It was always the intention the WebResource would be easily extensible and the current code falls short in that area. I'd be happy to discuss ways to improve the extensibility of the WebResources implementation on the dev@ list if anyone is interested in pursuing that option. Finally, another option if you need one JAR to override an other (which I don't think has been mentioned in this thread) is to extract the contents of that JAR to WEB-INF/classes which is guaranteed by the spec to be searched before JARs in WEB-INF/lib. As long as there are no conflicts, you could probably get away with doing this for multiple JARs if necessary. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
