Bug 37515 - smap not generated by JspC when used from Ant for precompilation
Summary: smap not generated by JspC when used from Ant for precompilation
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 5
Classification: Unclassified
Component: Jasper (show other bugs)
Version: 5.5.12
Hardware: All All
: P2 normal with 1 vote (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-11-15 22:57 UTC by Jess Holle
Modified: 2009-06-03 14:47 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jess Holle 2005-11-15 22:57:47 UTC
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...
Comment 1 Yoav Shapira 2006-04-13 19:46:46 UTC
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?
Comment 2 Jess Holle 2006-04-13 21:59:17 UTC
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...]
Comment 3 Jess Holle 2006-04-14 21:26:39 UTC
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.
Comment 4 william.barker 2006-04-16 02:10:00 UTC
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 :).
Comment 5 Jess Holle 2006-04-16 13:54:47 UTC
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.]
Comment 6 william.barker 2006-04-17 00:38:20 UTC
(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 ;-).
Comment 7 Jess Holle 2006-04-17 13:14:56 UTC
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).
Comment 8 Jess Holle 2006-04-17 13:21:17 UTC
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.
Comment 9 Mark Thomas 2009-01-03 16:26:31 UTC
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.
Comment 10 Jess Holle 2009-01-03 17:21:31 UTC
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).
Comment 11 Mark Thomas 2009-01-04 16:45:42 UTC
(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.
Comment 12 Jess Holle 2009-01-05 05:53:50 UTC
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.
Comment 13 Mark Thomas 2009-01-05 15:56:06 UTC
The JDT issue is a bug. I have committed a fix to trunk and proposed it for 6.0.x
Comment 14 Mark Thomas 2009-01-05 15:57:32 UTC
Add also proposed for 5.5.x
Comment 15 Jess Holle 2009-01-05 16:49:10 UTC
Thanks!
Comment 16 Mark Thomas 2009-01-14 16:31:05 UTC
This has been applied to 6.0.x and will be in 6.0.19 onwards.
Comment 17 Mark Thomas 2009-06-03 14:47:17 UTC
JDT 1.6/1/7 options added to 5.5.x and will be included in 5.5.28 onwards.