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 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).
I create a new fix based on Mark's comment: https://github.com/SuperMMX/tomcat/commit/1e5335629ca48608d59b3bc1247c853920157d46
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.
Fixed in 7.0.x as well for 7.0.64 onwards.
Thanks, your fix is much better than mine, I need to learn more about Tomcat codebase :)