Re: Latest JDT Compiler Issues.

2017-04-30 Thread Durga Srinivasu Karuturi
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.

2017-04-30 Thread Mark Thomas
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.

2017-04-30 Thread Durga Srinivasu Karuturi
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.

2017-04-30 Thread Mark Thomas
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

2017-04-30 Thread Mark Thomas
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 

Re: warning in tomcat logs

2017-04-30 Thread Mark Thomas
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

2017-04-30 Thread Mark Thomas
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

2017-04-30 Thread shivashankar manukondu
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