Community
Participate
Working Groups
I originally posted this at apache, but they forwarded me here. doing javap on a jsp generated servlet from 5.5.x starts with: Compiled from "org.apache.jsp.WEB_002dINF.jsp.components.globalheader_jsp" public final class org.apache.jsp.WEB_002dINF.jsp.components.globalheader_jsp extends org.apache.jasper.runtime.HttpJspBase implements org.apache.jasper.runtime.JspSourceDependent SourceFile: "org.apache.jsp.WEB_002dINF.jsp.components.globalheader_jsp" That is, the SourceFile attribute of this class is "org.apache.jsp.WEB_002dINF.jsp.components.globalheader_jsp" But this is incorrect, according to the java class file specification, specifically section: 4.7.7 The SourceFile Attribute "The string referenced by the sourcefile_index item will be interpreted as indicating the name of the source file from which this class file was compiled. It will not be interpreted as indicating the name of a directory containing the file or an absolute path name for the file; such platform- specific additional information must be supplied by the runtime interpreter or development tool at the time the file name is actually used." That means that for the above class, the SourceFile attribute should just be "globalheader_jsp.java" Note, no package or path info, as well as the .java extension. This wreaks havoc on tools such as BCEL, FindBugs, etc. original tomcat bug: http://issues.apache.org/bugzilla/show_bug.cgi?id=38776
Could you please provide steps to reproduce?
deploy web app with a jsp in it to tomcat 5.5.x browser to jsp page. run javap -v on the generated servlet corresponding to the jsp page. look at source attribute.
I'll try to reproduce using Tomcat 5.5.15.
Could you please provide a test case that fails? I tried the examples provided with Tomcat and they don't fail.
Looking at the source code of Tomcat 5.5.15, I wonder if the problem doesn't come from the constructor that creates compilation units. In the org.apache.jasper.compiler.JDTCompiler class: line 96. I can find: public char[] getFileName() { return className.toCharArray(); } should not this be: public char[] getFileName() { return sourceFile.toCharArray(); } Since the source file attribute is generated using the getFileName() result. This looks like the source of the problem. If you can provide a test case that fails, I could patch Tomcat and verify that this would fix this issue. Thanks.
Created attachment 35340 [details] war that shows sourcefile attr problems see test_jsp.class
example attached, click tryit, then do javap on C:\apache-tomcat-5.5.15\work\Catalina\localhost\sourcefile_attr\org\apache\jsp\jsp\test\test.jsp
ok, I reproduced the failure with your war file. Now I will try to patch my tomcat install to fix it the way I described in comment 5. I tried to get the source code to recompile it, but I still have lot of compiled errors because of missing classes.
If you patch your tomcat install with the suggested fix in comment 5, you then end up with: Compiled from "test_jsp.java" public final class org.apache.jsp.jsp.test.test_jsp extends org.apache.jasper.runtime.HttpJspBase implements org.apache.jasper.runtime.JspSourceDependent SourceFile: "test_jsp.java" SourceDebugExtension: length = 0x62 53 4D 41 50 0A 74 65 73 74 5F 6A 73 70 2E 6A 61 76 61 0A 4A 53 50 0A 2A 53 20 4A 53 50 0A 2A 46 0A 2B 20 30 20 74 65 73 74 2E 6A 73 70 0A 6A 73 70 2F 74 65 73 74 2F 74 65 73 74 2E 6A 73 70 0A 2A 4C 0A 31 3A 34 32 2C 32 0A 32 2C 33 3A 34 34 0A 35 3A 34 37 2C 33 0A 36 2C 33 3A 35 30 0A 2A 45 0A minor version: 0 major version: 49 Constant pool: const #1 = Asciz org/apache/jsp/jsp/test/test_jsp; const #2 = class #1; // org/apache/jsp/jsp/test/test_jsp const #3 = Asciz org/apache/jasper/runtime/HttpJspBase; const #4 = class #3; // org/apache/jasper/runtime/HttpJspBase const #5 = Asciz org/apache/jasper/runtime/JspSourceDependent; const #6 = class #5; // org/apache/jasper/runtime/JspSourceDependent const #7 = Asciz _jspx_dependants; const #8 = Asciz Ljava/util/List;; const #9 = Asciz <init>; const #10 = Asciz ()V; ... This looks much better. So from my perspective, the bug is related in the wrapper for the Eclipse compiler, not in the Eclipse compiler itself.
Closing as INVALID since the bug is not in the Eclipse compiler itself, but more in its wrapper defined in org.apache.jasper.compiler.JDTCompiler.
