tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject DO NOT REPLY [Bug 15964] New: - Wrong source paths in generated SMAP file entries
Date Fri, 10 Jan 2003 18:32:24 GMT

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

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 "" 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
"" 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
   "" 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:   <>
For additional commands, e-mail: <>

View raw message