DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15964>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15964 Wrong source paths in generated SMAP file entries Summary: Wrong source paths in generated SMAP file entries Product: Tomcat 5 Version: 5.0.0 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Jasper2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] One of the new features of Jasper in Tomcat 5 is that it attaches a "Source Map" attribute to class files to describe the file name and line number mapping from a JSP source file to the generated Java source file. According to JSR-45, each file entry in the SMAP defines a source name, and optionally, a source path. The SMAP that I see in the class files generated by Jasper doesn't specify a source path. This means that the source path defaults to a subdirectory based on the package of the class file. In other words, for class files generated by Jasper, the source path ends up being "org/apache/jsp". This is the source path for both the "JSP" stratum and the "Java" stratum. The problem is that this source path is wrong for both strata, given how Jasper stores files. An example would help explain this. Say the user wants to debug the "numguess.jsp" file that's part of the "jsp-examples" web application that comes with Tomcat. I've written a debugger that allows the user to enter directory names that the debugger should search for source files. Other debuggers have pretty much the same technique for finding source files. For this discussion, let's call this the debugger's "search path". Let's say the entries in the search path are "A" and "B". When a debugger wants to locate a source file corresponding to a particular location in a class, it uses the Java Debugging Interface (JDI) API to read the source name and source path for the stratum it intends to use for the display. Let's assume for the moment it wants to use the JSP stratum. So the debugger first looks for the file "A/org/apache/jsp/numguess.jsp", then for "B/org/apache/jsp/numguess.jsp". You get the idea. The problem is that there's no directory that the user could specify in the debugger's search path that allows the debugger to find the file, because the jsp file doesn't reside in a "org/apache/jsp" subdirectory of any directory. Instead, it resides in the "TH/webapps/jsp-examples/num" directory, where "TH" is the Tomcat home directory. One possibility would be for Jasper to specify "." (just a dot, meaning the current directory) as the source path in the SMAP for the JSP stratum. Then the user could enter "TH/webapps/jsp-examples/num" as the path to search. The debugger would be able to locate the file, since it would then be looking for "TH/webapps/jsp-examples/num/./numguess.jsp". But I have a better suggestion: How about specifying the subdirectory of the directory in which the web application is expanded? Continuing the example, this means specifying the source path "num" for the file "numguess.jsp". The user would then enter "TH/webapps/jsp-examples" into the debugger's search path. When the debugger tries to locate the file, it will paste together these three pieces and come up with "TH/webapps/jsp-examples/num/numguess.jsp", successfully finding the file. The advantage of this approach is that the user need only enter the top directory of the web application into the debugger's search path and the debugger will then be able to locate any JSP file for the web application. If "." were used, the user would need to enter every directory under the web application's top directory that contains a JSP to be debugged into the debugger's search path. A similar problem exists for the "Java" stratum. If the user of the debugger wanted to debug the JSP using the Java stratum, the debugger would try to locate the "numguess_jsp.java" file by searching the subdirectories of the debugger's search path. But again, the debugger would be unable to find the java file because it doesn't reside in a "org/apache/jsp" subdirectory of any directory. Just poking around, Jasper seems to put the Java source file under the "TH/work" directory, in my case in the directory "TH/work/Standalone/localhost/jsp-examples/num". The solution here isn't as simple as for the JSP stratum, however, since I don't think it's possible to change the source path for a file in the Java stratum in the SMAP. In other words, the source path for "numguess_jsp.java" is stuck being "org/apache/jsp", since that's the package the class is in. So, I can think of only two solutions: 1. Put the java file into the expected hierarchy. Perhaps designate that the "jsp" subdirectory of the web application's work directory will be the root of all jsp-related Java source files. Then change the Jasper source code generator to write the Java source file into the directory "TH/work/Standalone/localhost/jsp-examples/jsp/org/apache/jsp". So the user of the debugger would enter "TH/work/Standalone/localhost/jsp-examples/jsp" into the debugger's search path, allowing it to locate any Java source file generated by Jasper for that web application. I don't know if it's even necessary to create a "jsp" top directory. I suggested it only to keep these source and class files out the way of any other files in the work area, but if in fact the work area isn't used for anything else, then leave it off. 2. Change the package associated with the generated Java file, so that the source file can be found where it is today. I don't really like this suggestion, but I thought I'd mention it. In our example, this means generating the source such that the "numguess_jsp.java" source file starts with "package num" instead of "package org.apache.jsp". In this case, the user would enter "TH/work/Standalone/localhost/jsp-examples" into the debugger's search path, allowing it to locate any Java source file generated by Jasper for that web application. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
