On 29/04/17 11:10, Mohammed Manna wrote:
> 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.
Isn't that good? Doesn't that mean you've found a solution to the
problem? Compile with Ant and javac rather than JDT.
Mark
>
> <!-- 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
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
