Re: Latest JDT Compiler Issues.
Thanks mark for quick reply. Raised below issue for tracking purpose: https://bz.apache.org/bugzilla/show_bug.cgi?id=61057 Meanwhile we continue to use ecj-4.5.1 with latest tomcat 8.5.14. Thanks, Durga Srinivasu On Sun, Apr 30, 2017 at 11:52 PM, Mark Thomas wrote: > On 30/04/17 18:36, Durga Srinivasu Karuturi wrote: > > Hi, > > > > We have tried migrating tomcat from 8.5.11 --> 8.5.14 for latest security > > fixes and found our jasaperreports functionality is broken. > > > > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=495598 > > > > I have tried 4.5.1 (from old tomcat 8.5.11) and 4.6.2 (from > > http://central.maven.org/maven2/org/eclipse/scout/sdk/ > deps/ecj/4.6.2/ecj-4.6.2.jar) > > it works fine. > > > > Can we consider to change JDT to 4.6.2 in upcoming releases? > > Sure. Please open a Bugzilla issue to track this. > > > Mean while, is it okay to use old JDT 4.5.1 (ecj-4.5.1) with latest > tomcat > > 8.5.14? > > Yes, that should be fine. > > Mark > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Latest JDT Compiler Issues.
On 30/04/17 18:36, Durga Srinivasu Karuturi wrote: > Hi, > > We have tried migrating tomcat from 8.5.11 --> 8.5.14 for latest security > fixes and found our jasaperreports functionality is broken. > https://bugs.eclipse.org/bugs/show_bug.cgi?id=495598 > > I have tried 4.5.1 (from old tomcat 8.5.11) and 4.6.2 (from > http://central.maven.org/maven2/org/eclipse/scout/sdk/deps/ecj/4.6.2/ecj-4.6.2.jar) > it works fine. > > Can we consider to change JDT to 4.6.2 in upcoming releases? Sure. Please open a Bugzilla issue to track this. > Mean while, is it okay to use old JDT 4.5.1 (ecj-4.5.1) with latest tomcat > 8.5.14? Yes, that should be fine. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Latest JDT Compiler Issues.
Hi, We have tried migrating tomcat from 8.5.11 --> 8.5.14 for latest security fixes and found our jasaperreports functionality is broken. Reports compilation is failing with unresolved type errors even though all related jars are in classpath 1. java.util.ResourceBundle cannot be resolved to a type value = ((java.util.ResourceBundle) parameter_REPORT_RESOURCE_BUNDLE.getValue()); //$JR_EXPR_ID=34$ <--> 2. net.sf.jasperreports.engine.JRDataSource cannot be resolved to a type value = ((net.sf.jasperreports.engine. JRDataSource)parameter_DS_controllers_by_model609.getValue()); //$JR_EXPR_ID=37$ <--> 3. net.sf.jasperreports.engine.JasperReport cannot be resolved to a type value = ((net.sf.jasperreports.engine. JasperReport)parameter_SR_controllers_by_model609.getValue()); //$JR_EXPR_ID=38$ <--> 4. java.util.ResourceBundle cannot be resolved to a type value = ((java.util.ResourceBundle) parameter_REPORT_RESOURCE_BUNDLE.getValue()); //$JR_EXPR_ID=40$ <--> Debugged further and found this is because of 4.6.1 JDT compiler change from 8.5.12. This is a regression issue from JDT 4.6.1 https://bugs.eclipse.org/bugs/show_bug.cgi?id=495598 I have tried 4.5.1 (from old tomcat 8.5.11) and 4.6.2 (from http://central.maven.org/maven2/org/eclipse/scout/sdk/deps/ecj/4.6.2/ecj-4.6.2.jar) it works fine. Can we consider to change JDT to 4.6.2 in upcoming releases? Mean while, is it okay to use old JDT 4.5.1 (ecj-4.5.1) with latest tomcat 8.5.14? Thanks, Durga Srinivasu
Re: tomcat ant test failure due to java exception.
On 29/04/17 03:47, Arjit Gupta wrote: > Hi, > > I am building tomcat 7.0.77 with java7 on HP-UX(OS) itanium(IA64) processor. > After building it successful I am running *ant test*. > Multiple tests are failing due to below exception. > > *Exception in thread "Thread-18" java.lang.AssertionError: Option not found* Full stack trace for one of those errors? Mark > > Fail test cases are:- > 175 > > TEST-org.apache.catalina.tribes.group.TestGroupChannelSenderConnections.BIO.txt:Tests > run: 3, Failures: 3, Errors: 0, Time elapsed: 9.213 sec > 176 > > TEST-org.apache.catalina.tribes.group.TestGroupChannelSenderConnections.NIO.txt:Tests > run: 3, Failures: 3, Errors: 0, Time elapsed: 9.572 sec > 183 > > TEST-org.apache.catalina.tribes.group.interceptors.TestNonBlockingCoordinator.BIO.txt:Tests > run: 2, Failures: 2, Errors: 0, Time elapsed: 43.762 sec > 184 > > TEST-org.apache.catalina.tribes.group.interceptors.TestNonBlockingCoordinator.NIO.txt:Tests > run: 2, Failures: 2, Errors: 0, Time elapsed: 43.897 sec > 185 > > TEST-org.apache.catalina.tribes.group.interceptors.TestOrderInterceptor.BIO.txt:Tests > run: 2, Failures: 2, Errors: 0, Time elapsed: 30.797 sec > 186 > > TEST-org.apache.catalina.tribes.group.interceptors.TestOrderInterceptor.NIO.txt:Tests > run: 2, Failures: 2, Errors: 0, Time elapsed: 31.078 sec > 187 > > TEST-org.apache.catalina.tribes.group.interceptors.TestTcpFailureDetector.BIO.txt:Tests > run: 3, Failures: 2, Errors: 0, Time elapsed: 27.097 sec > 188 > > TEST-org.apache.catalina.tribes.group.interceptors.TestTcpFailureDetector.NIO.txt:Tests > run: 3, Failures: 2, Errors: 0, Time elapsed: 33.172 sec > 359 TEST-org.apache.tomcat.util.net.TestClientCert.BIO.txt:Tests run: 5, > Failures: 0, Errors: 5, Time elapsed: 7.45 sec > 360 TEST-org.apache.tomcat.util.net.TestClientCert.NIO.txt:Tests run: 5, > Failures: 0, Errors: 5, Time elapsed: 8.081 sec > 361 TEST-org.apache.tomcat.util.net.TestCustomSsl.BIO.txt:Tests run: 3, > Failures: 0, Errors: 3, Time elapsed: 7.54 sec > 362 TEST-org.apache.tomcat.util.net.TestCustomSsl.NIO.txt:Tests run: 3, > Failures: 0, Errors: 3, Time elapsed: 8.156 sec > 363 TEST-org.apache.tomcat.util.net.TestSsl.BIO.txt:Tests run: 4, > Failures: 0, Errors: 3, Time elapsed: 8.117 sec > 364 TEST-org.apache.tomcat.util.net.TestSsl.NIO.txt:Tests run: 4, > Failures: 0, Errors: 3, Time elapsed: 8.933 sec > > Arjit Kumar > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fwd: Identifying 64k size violation for __jspService methods loaded by Tomcat
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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> validateXml="false"
> uriroot="webapps/${webdir}"
> webXmlFragment="work/generated_web.xml"
> outputDir="work/jsp"
> smapsuppressed="0"
> compilersourcevm="1.8"
> compilertargetvm="1.8"
> mappedfile="1"/>
>
>
>
>
> destdir="work/jsp"
> optimize="off"
> debug="on"
> failOnError="false"
> srcdir="work/jsp">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 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 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 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:
>>>
Re: warning in tomcat logs
On 29/04/17 15:13, George Stanchev wrote: > TC 8.5.14 and noticed in the logs the following warning: > > "The truststoreProvider [AnyCert] does not support the > certificateVerificationDepth configuration option" > > In our case, we're using Shib's AnyCert trust manager to accept any > client cert on a particular connector as described here [1]. I > noticed that now one can inject the trust manager directly via > "trustManagerClassName" so I am planning to go that route to > eliminate the warning from the logs. But I looked at > JSSEUtils.java#getTrustManagers() and it looks like the warning is > emitted for any algorithm other than "PKIX". My question is, what if > an algorithm implementation doesn't care about > "certificateVerificationDepth"? By setting different algorithm the > user should realize that they are deviating from PKIX and therefore > configuration parameters that apply to PKIX (such as > "trustMaxCertLength" would not be passed down to the trust manager. > Doesn't it make sense to be logged at INFO level? I think not. What would be better is if the warning was only logged if the attribute was explicitly set. Mark > George > > > [1] > https://wiki.shibboleth.net/confluence/display/SHIB/TomcatClientCertAuthN > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Auto Shutdown issues
On 29/04/17 16:23, Naveen Nandyala - Vendor wrote: > Hi Team, > > We are using Tomcat "7.0.61.0", and running on SUSE Linux Enterprise > Server 11 (x86_64), Version 11, and PatchLevel 3. Our tomcat > instance is going down due to below message, No it isn't. Something is shutting down Tomcat. That in turn causes Tomcat to stop each of the web applications. One of those web applications has a memory leak and Tomcat is reporting it. For an explanation of the memory leak, see my presentation from 2010 [1]. Mark [1] http://tomcat.apache.org/presentations.html > and its not a normal > shutdown we are not sure why and who is causing to throw this > messages and causing tomcat instance go down. Can anyone provide > some inputs for cause of this and how can we debug what is causing. > > Below is op from catalina logs. > > > Apr 26, 2017 12:38:41 PM org.apache.coyote.AbstractProtocol pause > INFO: Pausing ProtocolHandler ["http-nio-61034"] Apr 26, 2017 > 12:38:41 PM org.apache.catalina.core.StandardService stopInternal > INFO: Stopping service Catalina Apr 26, 2017 12:38:52 PM > org.apache.catalina.loader.WebappClassLoader clearReferencesJdbc > SEVERE: The web application [/MainframeJobRequest] registered the > JDBC driver [com.ibm.db2.jcc.DB2Driver] but failed to unregister it > when the web application was stopped. To prevent a memory leak , the > JDBC Driver has been forcibly unregistered. Apr 26, 2017 12:38:52 PM > org.apache.coyote.AbstractProtocol stop INFO: Stopping > ProtocolHandler ["http-nio-61034"] Apr 26, 2017 12:38:52 PM > org.apache.coyote.AbstractProtocol destroy > > > > Warm Regards, Naveen Kumar Reddy N > > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Auto Shutdown issues
Hi, Looks like it is not able to unregistered during closing the DataSource - which causes memory leak, and Tomcat complains about it. Check in your web application if any jdbc unregister method using, also try to move your jdbc drivers to tomcat common lib directory instead of using in web application. Regards, Siva On Sun, Apr 30, 2017 at 6:47 AM, Naga Ramesh wrote: > Naveen, > > Can u provide the setenv changes and total system RAM and free RAM output > for need to investigation > > Regards, > Ramesh > On Apr 29, 2017 8:53 PM, "Naveen Nandyala - Vendor" < > naveen.nandy...@walmart.com> wrote: > > > Hi Team, > > > > We are using Tomcat "7.0.61.0", and running on SUSE Linux > > Enterprise Server 11 (x86_64), Version 11, and PatchLevel 3. Our tomcat > > instance is going down due to below message, and its not a normal > shutdown > > we are not sure why and who is causing to throw this messages and causing > > tomcat instance go down. Can anyone provide some inputs for cause of > this > > and how can we debug what is causing. > > > > Below is op from catalina logs. > > > > > > Apr 26, 2017 12:38:41 PM org.apache.coyote.AbstractProtocol pause > > INFO: Pausing ProtocolHandler ["http-nio-61034"] > > Apr 26, 2017 12:38:41 PM org.apache.catalina.core.StandardService > > stopInternal > > INFO: Stopping service Catalina > > Apr 26, 2017 12:38:52 PM org.apache.catalina.loader.WebappClassLoader > > clearReferencesJdbc > > SEVERE: The web application [/MainframeJobRequest] registered the JDBC > > driver [com.ibm.db2.jcc.DB2Driver] but failed to unregister it when the > web > > application was stopped. To prevent a memory leak > > , the JDBC Driver has been forcibly unregistered. > > Apr 26, 2017 12:38:52 PM org.apache.coyote.AbstractProtocol stop > > INFO: Stopping ProtocolHandler ["http-nio-61034"] > > Apr 26, 2017 12:38:52 PM org.apache.coyote.AbstractProtocol destroy > > > > > > > > Warm Regards, > > Naveen Kumar Reddy N > > > > > > > -- Regards Siva #068860592040
