Hello,
I have retried using the following javac and jasper settings for my project
(using ANT build) - and it still doesn't reveal those 64K errors even when
the compilers are the same.
<!-- Configure Jasper -->
<target name="jspc" depends="build.web">
<taskdef classname="org.apache.jasper.JspC" name="jasper2">
<classpath id="jspc.classpath">
<pathelement location="${java.home}/../lib/tools.jar"/>
<fileset dir="bin">
<include name="*.jar"/>
</fileset>
<fileset dir="lib">
<include name="*.jar"/>
</fileset>
</classpath>
</taskdef>
<jasper2
validateXml="false"
uriroot="webapps/${webdir}"
webXmlFragment="work/generated_web.xml"
outputDir="work/jsp"
smapsuppressed="0"
compilersourcevm="1.8"
compilertargetvm="1.8"
mappedfile="1"/>
</target>
<!-- Compile JSP -->
<target name="compile.jsp" depends="jspc" >
<javac compiler="javac1.8"
destdir="work/jsp"
optimize="off"
debug="on"
failOnError="false"
srcdir="work/jsp">
<classpath>
<pathelement location="webapps/${webdir}/WEB-INF/classes"/>
<fileset dir="webapps/${webdir}/WEB-INF/lib">
<include name="*.jar"/>
</fileset>
<fileset dir="lib">
<include name="*.jar"/>
</fileset>
<fileset dir="bin">
<include name="*.jar"/>
</fileset>
</classpath>
<include name="**"/>
<exclude name="tags/**"/>
</javac>
</target>
I set my environment variables for catalina and java as part of my tomcat
start script. And both ANT and Tomcat are using the same compiler as i
understand from ant task documentation. Is there anything else I can do to
reveal the 64k size errors on the method?
KR,
On 26 April 2017 at 11:24, Mark Thomas <ma...@apache.org> wrote:
> On 26/04/17 10:33, Mohammed Manna wrote:
> > Hello,
> >
> > Thanks for suggesting the solutions. This is closer to what I was
> expecting
> > in the original message which I sent in the past. Once again, I
> apologise
> > if I have made any Negative/Reactive comments about Apache no being
> > supportive enough. I have been using various Apache libraries over the
> past
> > 7 years without any issues. But this particular Tomcat upgrade has caused
> > me significant grief in managing large projects where 9/10 systems are
> > legacy code base. I do agree that the JSPs need to be refactored to
> remove
> > any obsolescence. But until your response, I have only received responses
> > where I was asked to upgrade to a different version, but I am more
> curious
> > to find out the root cause for this.
> >
> > Unfortunately, I have to leave with *enablePooling=TRUE, *since it might
> > affect things. I will however try to reconfigure Jasper and use my native
> > Java 1.8.121 to do all the compilation and see how things go.
> >
> > Unless I have misunderstood, Tomcat 8.0.43 will not stop this error but
> > minimise the occurrences of it. Is this correct?
>
> Correct. The error handling code was refactored for 8.0.42 onwards to be
> a little more efficient. It isn't much but if your code is on the border
> line it might be enough to bring it back under the 64k.
>
> Mark
>
>
> >
> >
> > Additionally, thanks to you for putting a lot more attention to it.
> >
> > KR,
> >
> >
> >
> >
> > On 26 April 2017 at 09:58, Mark Thomas <ma...@apache.org> wrote:
> >
> >> On 26/04/17 09:06, Mohammed Manna wrote:
> >>> Hello,
> >>>
> >>> I have emailed and posted a few questions over the web about this, but
> >>> haven't received any helpful response. Since the upgrade to 8.0.39, my
> >> web
> >>> application is failing in various places since the Jasper compiler has
> >> now
> >>> got more debug information (and inturn __jspService method is now
> bigger
> >>> than 64k).
> >>
> >> First a correction. The changes were not made to introduce additional
> >> debug information. The changes introduced additional - specification
> >> required - error handling for tags. The changes were the result of
> >> investigating a reported memory leak [1].
> >>
> >>> I have done the following so far:
> >>>
> >>> 1) Kept mappedFile = TRUE
> >>> 2) Kept suppressSMAP = FALSE
> >>>
> >>> This removes the failure, but now I have lost the JSP debugging
> >> capability.
> >>> Since Apache is not going to provide any support for this, could you
> >> kindly
> >>> assist me with the following:
> >>
> >> First you say Apache isn't going to provide you with any support
> >> (despite this being your first post on this topic) then you ask this
> >> Apache community for that same support. That isn't the best way to
> >> motivate a group of volunteers to help you.
> >>
> >> The initial fix was in 8.0.37.
> >> A regression was fixed in 8.0.40.
> >> A more efficient solution was provided in 8.0.42.
> >> An improved solution for simple tags was in 8.0.43
> >>
> >> The first recommendation is to upgrade to 8.0.43. The more efficient
> >> code introduced in 8.0.42 may help.
> >>
> >> Other configuration settings that can help reduce the size of your JSP
> >> methods include:
> >>
> >> trimSpaces - true
> >> enablePooling - false
> >>
> >> Note the disabling pooling may impact performance. It depends on lot on
> >> the complexity of the tags.
> >>
> >>> 1) How can I identify my JSP pages which are going to have this issue?
> >>> 2) I have tried using ANT build and compiled my JSPs. It simply passes
> >> the
> >>> build, but doesn't report any method size violation. Do you have any
> >>> development mode support that can expose these affected methods.
> >>
> >> Do those pre-compiled JSPs then execute without error?
> >>
> >> Pre-compilation typically uses javac whereas on the fly compilation
> >> typically uses JDT (the Eclipse Compiler). It is possible that
> >> differences in the compilers means that a class compiles with one but
> >> fails with the other - particularly if your code is close to the
> boundary.
> >>
> >> It is possible to configure Jasper to compile JSPs with Ant and javac
> >> (see the compiler init parameter).
> >>
> >> I suggest you try the recommendations above and see how you get on.
> >>
> >>> I appreciate that these are too specific questions, but Tomcat 8.0.39
> >>> upgrade clearly didn't consider legacy systems and has left a massive
> >>> refactoring job to the developers. So, it would be great if you could
> >>> proactively extend "Known Issues" section with these.
> >>
> >> Patches welcome.
> >>
> >> Mark
> >>
> >>
> >> [1] http://tomcat.markmail.org/thread/6jz7wfpcse6oxdgd
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
