|Summary:||Incorrect CodeSource location from ProtectionDomain for classes in WEB-INF/classes|
|Product:||Tomcat 7||Reporter:||Xuan MA <supermmx>|
|Component:||Catalina||Assignee:||Tomcat Developers Mailing List <dev>|
Description Xuan MA 2015-07-02 22:41:40 UTC
I tried a very simple webapp, with a test.jsp and WEB-INF/classes/test/pkg/Test.class on both Tomcat 7 and Tomcat 8 latest version (with Java 7 and Java 8 respectively) ==== test.jsp ==== Test: <%= test.pkg.Test.class.getProtectionDomain().getCodeSource().getLocation() %> ================== and Tomcat 8 shows Test: file:/C:/Install/apache-tomcat-8.0.23/webapps/test/WEB-INF/classe/test/pkg/Test.class Tomcat 7 shows the similar result. In a standalone Java program, the similar code shows the top-level classpath entry like xxx/classes where test/pkg/Test.class is saved. I also tried Jetty, it shows it correctly like: Test: file:/C:/Install/jetty-distribution-9.3.0.v20150612/test-base/webapps/test/WEB-INF/classes/ So what I expect is WEB-INF/classes, is there any reason why Tomcat returns the full path of the class file instead of WEB-INF/classes ? I have a quick fix to get what I want, but not sure whether there are other impacts, at least all unit tests are passed except two TEST-org.apache.catalina.filters.TestRemoteIpFilter.*. The fix is here: https://github.com/SuperMMX/tomcat/commit/a96b4a80144f78140690fd35e47d0fdd1a64d0ae
Comment 1 Xuan MA 2015-07-02 22:43:10 UTC
Comment from Mark Thomas: I've taken a quick look and the issue looks valid. I'm not sure about the proposed fix though. It is almost certainly better to correct the value returned by getCodeBase() (fix the root cause, not one of the symptoms).
Comment 2 Xuan MA 2015-07-03 05:19:44 UTC
I create a new fix based on Mark's comment: https://github.com/SuperMMX/tomcat/commit/1e5335629ca48608d59b3bc1247c853920157d46
Comment 3 Mark Thomas 2015-07-06 10:31:55 UTC
Thanks for the patch. I took a slightly different approach which was to use getURL() on the resource obtained for "/WEB-INF/classes/". The fix has been applied to trunk (for 9.0.x) and to 8.0.x for 8.0.25 onwards. 7.0.x will need a different fix since it uses a different resources implementation.
Comment 4 Mark Thomas 2015-07-06 13:31:53 UTC
Fixed in 7.0.x as well for 7.0.64 onwards.
Comment 5 Xuan MA 2015-07-06 22:03:55 UTC
Thanks, your fix is much better than mine, I need to learn more about Tomcat codebase :)