I've noticed that in Tomcat 5.5.12 one can pass the JspC task an smapSuppressed attribute. Unfortunately, it appears that one *still* cannot do source-level debugging of JSPs when they are precompiled via JspC with smapSuppressed=false in 5.5.12. Note that the same JSP are source-level debuggable in exactly the same set up if they are compiled on the fly by Tomcat. Unfortunately I am baffled as to why this does not work...
Jess, I know you test practically every Tomcat release, and IIRC 5.5.15 introduced better source-level debugging for JSPs. Has this gone away, or is it still an issue?
I am using 5.5.15 these days, but have not given this a try lately. I'll try to find a spare few minutes to try this. [I may have tossed my old test Ant script, unfortunately...]
I just tested this again with 5.5.15 -- and it is still broken. The issue is that if I use a precompilation Ant script, containing something like: <target name="-jspc" unless="nojspc"> <!-- Description: Produces Java sources for the JSP files specified by 'jspFileList' --> <taskdef classname="org.apache.jasper.JspC" name="jasper2" > <classpath id="jspc.classpath"> <pathelement location="${java.home}/../lib/tools.jar"/> <fileset dir="${tomcatHome}/bin"> <include name="*.jar"/> </fileset> <fileset dir="${tomcatHome}/server/lib"> <include name="*.jar"/> </fileset> <fileset dir="${tomcatHome}/common/lib"> <include name="*.jar"/> </fileset> </classpath> </taskdef> <condition property="jspcVerbosityLevel" value="999"> <istrue value="${verboseJspc}"/> </condition> <property name="jspcVerbosityLevel" value="0"/> <jasper2 uriroot="${docBase}" smapSuppressed="false" outputDir="${jspcJavaOutputDir}" webXmlFragment="${jspcJavaOutputDir}/generated_web.xml" compilerSourceVM="${sourceVer}" compilerTargetVM="${targetVer}" validateXml="false" listErrors="true" verbose="${jspcVerbosityLevel}" jspFiles="${jspFileList}"/> </target> everything works fine *except* SMAP output appears to always be suppressed -- even though I'm explicitly using smapSuppressed="false". I use the fragment above in the context of a larger, Ant script. Breakpoints I set in JSPs with my IDE (NetBeans 5) are ignored. I remove one of the precompiled classes and reload the page in the browser -- and suddenly the breakpoints work just fine. I also note there is a notable size difference between class file sizes in these cases (e.g. 6.96KB vs. 7.54KB in a test case). Thus overall I'm pretty sure the SMAP data is getting suppressed when invoked from precompilation, even though I don't know how to verify this with certainty from a class file.
This is probably heading to a variant of WONTFIX. I spent some time on this (by changing the /admin precompile in the default build.xml), and the results are: With your settings, the smap info is generated and thrown away. Using compile="true" (and fixing the output dir) seems to work. It's possible that there are some combinations of options that will get dumpSmap="true" to work as well (but I haven't found them :).
Can you specify a custom classpath with compile="true"? [I need one -- I use a custom web app classloader to this effect and need the same effect when I precompile.]
(In reply to comment #5) > Can you specify a custom classpath with compile="true"? > [I need one -- I use a custom web app classloader to this effect and need the > same effect when I precompile.] From my (limited :) understanding of Ant, I believe the answer is 'yes'. Of course, just trying it would give you the answer much faster than asking ;-).
I tried: <jasper2 uriroot="${docBase}" outputDir="${jspcJavaOutputDir}" compile="true" classpath="${docBase}" webXmlFragment="${jspcJavaOutputDir}/generated_web.xml" compilerSourceVM="${sourceVer}" compilerTargetVM="${targetVer}" validateXml="false" listErrors="true" verbose="${jspcVerbosityLevel}" jspFiles="${jspFileList}"/> [Yes, I need the classpath bit.] The JSPs compiled fine -- but with no SMAP info (in 5.5.15).
I tried smapDumped="true" as well to no avail. Also, my settings (with no 'compile="true"') are essentially those shown in the documentation -- so if there is a limitation as serious as losing SMAP info with not having JspC do the Java compilation (which it doesn't by default), then this should be noted in the documentation. Overall, I have yet to get any combination to work.
I have added a comment to the 5.5.x and 6.x docs. compile="true" and supressSmap="false" works for me with the latest 5.5.x code. I did toy with the idea of an enhancement request for a new Ant task that merged the smap info into the generated classes but I couldn't see anything that would achieve that isn't achieved by using JspC.
The issue with using compile="true" is that it does not give as much control over compilation. For starters we use a custom extension to the web app classloader to introduce another directory to the classpath *before* WEB-INF/classes. That's the main item -- we could probably live with just using compile="true" if we could control the compilation classpath. We also use UTF-8 as the encoding for javac, but I believe jspc must do so internally as well -- as that's what it produces. [By the way, the documentation should really make the fact that jspc produces UTF-8 Java sources clear as this is not the normal default for Java sources or javac.] I'm re-opening this since there is a use case for compile="false", but I'll understand if that use case is insufficiently interesting to everyone else (as we can work around this ourselves as well by not using pre-compiled JSPs when debugging).
(In reply to comment #10) > The issue with using compile="true" is that it does not give as much control > over compilation. For starters we use a custom extension to the web app > classloader to introduce another directory to the classpath *before* > WEB-INF/classes. That should be fine. If you set the classpath attribute of Jasper2 WEB-INF/classes and web-INF/lib get added to the end of whatever you set. > We also > use UTF-8 as the encoding for javac, but I believe jspc must do so internally > as well -- as that's what it produces. [By the way, the documentation should > really make the fact that jspc produces UTF-8 Java sources clear as this is not > the normal default for Java sources or javac.] I'll check what is going on and update the docs as required. > I'm re-opening this since there is a use case for compile="false", but I'll > understand if that use case is insufficiently interesting to everyone else (as > we can work around this ourselves as well by not using pre-compiled JSPs when > debugging). I'm not clear what this use case is. What is it that you can't do with compile="true" that you can do with compile="false"? Note that I used the latest 5.5.x to test with the default build.xml for JspC (from the docs) plus classpath="${webapp.path}" smapSuppressed="false" compile="true" and the Smap info was included in the class files.
Somehow I missed the classpath attribute. That indeed solves my problem. I have one much smaller (nuisance) problem. I want to specify -source and -target of 1.6 -- as I would with javac. The JDT used by JspC by default complains about this claiming it does not understand a value of 1.6 here, which is silly -- 1.6 has been out a long time now and does have slightly different byte-code output than previous Java versions. I could presumably force use of javac, but I'd rather be more consistent with on-the-fly JSP compilation. Yes, I could force use of javac there as well, but I'd rather not. Is there no JDT available that understands a -source/-target of 1.6? Feel free to close the bug, but some answer about the JDT issue would be appreciated.
The JDT issue is a bug. I have committed a fix to trunk and proposed it for 6.0.x
Add also proposed for 5.5.x
Thanks!
This has been applied to 6.0.x and will be in 6.0.19 onwards.
JDT 1.6/1/7 options added to 5.5.x and will be included in 5.5.28 onwards.