After updating to Tomcat V7.0.78 from V7.0.54 JSP compilation fails due to 65535 bytes limit

[Rahul Singh]

Hi Tomcat Team,

Thanks for your always support and guidence !!

In one of the web application Tomcat is migrated from V7.0.54 to V7.0.78. After 
update one phenomena is reported regarding JSP file compilation at run time.


>From stack trace analysis it is evident that JSP to JAVA compilation is 
>surpassing the 65535 bytes limit.

After analysis we have found some solution, but we would like to knowin which 
version this chnage is introduced BW Tomcat 7.0.54 and Tomcat 7.0.78. If 
possible we would like to know what chnages has been done in tomcat that leads 
to this phenomena.

JFYI, Same JSP was succesfully executed and compiled in Tomcat 7.0.54. and no 
information is mentioned in chnagelogs and relase notes related to this 
phenomena.

Your eraly response is highly appriciated !!


Regards,

Rahul kumar Singh

Re: Tomcat 7.0.54 gives zero-byte .java and .class files for jsp in work directory that cause truncated class error

[Rahul Singh]

Dear Christopher,


Thanks you very much for your response !!


>Filesystem quota?


Filesystem Quota is not enabled for this disk partition so there is no 
restrictions on disk usage.


>Look at the timestamps on the zero-byte files, then find that same
>place in catalina.out or one of the other Tomcat-specific log files.
>See if there's anything in those log files that gives a reason for the
>failure to compile your JSPs.


We have seen the catlina.out and other tomcat logs but no such evidence 
regarding the compilation of JSP.


during googling in various forums, we have observed that the same problem is 
occurred to one of the senior engineer of google, and it is unresolved/open yet.


reference: 
http://stackoverflow.com/questions/8813509/how-does-tomcat-generate-its-work-directory-jsp-java-files-and-what-might-cau


It is very critical problem in our production environments (occurring Many 
production environments),  and it is raised as tomcat specific problem so 
occurrence condition and root cause may be required from tomcat team.



Regards,

Rahul Kumar Singh







From: Christopher Schultz 
Sent: Sunday, July 31, 2016 5:38:13 PM
To: Tomcat Users List
Subject: Re: Tomcat 7.0.54 gives zero-byte .java and .class files for jsp in 
work directory that cause truncated class error

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Rahul,

On 7/28/16 1:50 AM, Rahul Singh wrote:
> Hi tomcat team, Thanks for your continued support and help.
>
> I am facing the a peculiar problem in Tomcat 7.0.54.

Any chance for a Tomcat upgrade? Also, Java 7 has reached End-of-Life.

> Configurations: OS: RHEL Tomcat:7.0.54 Java:1.7.79

If you are using RHEL packages, you may not have an upgrade path. :(

> A jsp that was running properly gave the following exception after
> graceful tomcat restart
>
>  javax.servlet.ServletException:
> java.lang.ClassFormatError: Truncated class file at
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:343)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli
cationFilterChain.java:303)
>
>
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
erChain.java:208)
> at
> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
>
>
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:241)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFi
lterChain.java:208)
>
>
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatc
her.java:748)
> at
> org.apache.catalina.core.ApplicationDispatcher.processRequest(Applicat
ionDispatcher.java:486)
>
>
at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDisp
atcher.java:411)
> at
> org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDisp
atcher.java:338)
>
>
at
org.apache.struts2.dispatcher.ServletDispatcherResult.doExecute(ServletD
ispatcherResult.java:154)
> at
> org.apache.struts2.dispatcher.StrutsResultSupport.execute(StrutsResult
Support.java:186)
>
>
at
com.opensymphony.xwork2.DefaultActionInvocation.executeResult(DefaultAct
ionInvocation.java:362)
> at
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionIn
vocation.java:266)
>
>  
>
> On checking the Tomcat work directory we discovered that the
> corresponding .java and .class files were of zero byte size. In
> other words these files were empty. This was the main reason why
> Tomcat gave truncated class error. Corresponding to this we also
> checked the disk utilization but it was at 54% only. So any
> possibility for disk space are ruled out.

Filesystem quota?

> Also that the same jsp had not been modified and was running
> properly initially. so after reboot of tomcat what happen? why the
> jsp.java and jsp.class size is generated of 0 bytes.
>
> So my question is that what might have caused tomcat to generate
> empty *_jsp.java files in its work directory?
>
> Hope tomcat team will help us to finding root cause.

Look at the timestamps on the zero-byte files, then find that same
place in catalina.out or one of the other Tomcat-specific log files.
See if there's anything in those log files that gives a reason for the
failure to compile your JSPs.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAled6i0ACgkQ9CaO5/Lv0PB59ACePn8ro2YsATZjgDFh8lTH1dU/
T5YAnjxaL4LZB4BdfL/wTJuPEeBfT4fh
=pvZ5
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Tomcat 7.0.54 gives zero-byte .java and .class files for jsp in work directory that cause truncated class error

[Rahul Singh]

Hi tomcat team,
Thanks for your continued support and help.

I am facing the a peculiar problem in Tomcat 7.0.54.

Configurations:
OS: RHEL
Tomcat:7.0.54
Java:1.7.79


A jsp that was running properly gave the following exception after graceful 
tomcat restart


javax.servlet.ServletException: java.lang.ClassFormatError: Truncated class file
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:343)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at 
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:748)
at 
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:486)
at 
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:411)
at 
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:338)
at 
org.apache.struts2.dispatcher.ServletDispatcherResult.doExecute(ServletDispatcherResult.java:154)
at 
org.apache.struts2.dispatcher.StrutsResultSupport.execute(StrutsResultSupport.java:186)
at 
com.opensymphony.xwork2.DefaultActionInvocation.executeResult(DefaultActionInvocation.java:362)
at 
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:266)



On checking the Tomcat work directory we discovered that the corresponding 
.java and .class files were of zero byte size.
In other words these files were empty. This was the main reason why Tomcat gave 
truncated class error.
Corresponding to this we also checked the disk utilization but it was at 54% 
only. So any possibility for disk space
are ruled out.
Also that the same jsp had not been modified and was running properly 
initially. so after reboot of tomcat
what happen? why the jsp.java and jsp.class size is generated of 0 bytes.

So my question is that what might have caused tomcat to generate empty 
*_jsp.java files in its work directory?

Hope tomcat team will help us to finding root cause.

Regards,
Rahul Kumar singh

Http POST request is getting tempered in Tomcat7

[Rahul Singh]

Hello Tomcat Team,

Thanks for your always support !!

We have a Struts 2 application with Tomcat 7 that runs on a proxy network. In 
one partcular case while browsing the application
it was observed that simply navigating one particular screen multiple times 
raised a NoSuchMethodException exception once.

This was observed in IE-10 browser running on Windows 8. It was occuring on a 
single system only and could not be reproduced on other systems..

The request as obatined in Tomcat catalina logs is as follows:
192.168.103.105 - - [14/Jul/2016:15:41:54 +] "POST 
/application/framework/SessionAction.action HTTP/1.1" 200 105
192.168.103.105 - - [14/Jul/2016:15:41:54 +] "POST 
/application/framework/SessionAction.action HTTP/1.1" 200 105
192.168.103.105 - - [14/Jul/2016:15:41:55 +] "CHEDFLAG=TRUEPOST 
/application/framework/SessionAction.action HTTP/1.1" 200 58209

Also when used Internet Explorer to debug the request we get the following 
details for the problem scenario:

Request Headers
Key Value
Request POST http://192.168.133.120/Myapp/application/rpc_SessionAction.action 
HTTP/1.1
Referer http://192.168.133.120:8585/application/
Content-Type application/x-www-form-urlencoded
X-Requested-With XMLHttpRequest
Accept application/json, text/javascript, /
Accept-Language en-IN,en;q=0.8,ja;q=0.6,zh-Hans-CN;q=0.4,zh-Hans;q=0.2
Accept-Encoding gzip, deflate
User-Agent Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; WOW64; 
Trident/6.0)
Host 192.168.133.120:8585
Content-Length 26
DNT 1
Proxy-Connection Keep-Alive
Pragma no-cache
Cookie JSESSIONID=7FE4DE04F3558B46B7D8252645ABFB5A; 
JSESSIONID=D4FD5A0D120AD35414A4E16C406DD06F


Request Body
method=fetch&names=tmpVal

Response Headers
Key Value
Response HTTP/1.0 200 OK
Server Apache-Coyote/1.1
Content-Type text/html;charset=utf-8
Date Thu, 14 Jul 2016 15:41:55 GMT
X-Cache MISS from gateway1
X-Cache-Lookup MISS from gateway1
Via 1.0 gateway1



This request in the Struts filter gives null entry set. Why does the POST 
request get changed in this case and also entry set bencomes null?


Regards,

Rahul Kumar Singh

Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]

[Rahul Singh]

Apart from below information, one additional information.

We have used the jQuery form plugin js in our project. This handles the form 
and request submit. The code is as attached here.





From: Rahul Singh 
Sent: Tuesday, January 19, 2016 11:30 AM
To: Tomcat Users List
Subject: Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 
Struts: 2.3.24 JAVA: openJDK 1.7.79]

Hi Christopher ,


>>So... what makes you sure that the browser actually made the request?
>>I'd like to see some kind of confirmation using a tool you didn't
>>write. Perhaps something like Firebug, LiveHttpHeaders, Fiddler, or
>>even Wireshark showing that the request was made, what headers it had,
>>etc.

OK,
We have used HTTP Analayzer for file upload via Internet Explorer-8. Following 
are the scenario observed.

For lesser than 2gb file uploads : The request header shows the correct 
content-length value of the file.The uploads works fine further also.

For more than 2gb file uploads: The file length is 2151533567 bytes(which is 
roughly 2.15 Gb).  The request is aborted in this case and the request header 
shows the content length
as -214343325 bytes (which is rougly 214 Mb).The upload process does not 
proceed further in this case.

both cases request headers are attached in screenshot.

From: Christopher Schultz 
Sent: Monday, January 18, 2016 11:17 AM
To: Tomcat Users List
Subject: Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 
Struts: 2.3.24 JAVA: openJDK 1.7.79]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Rahul,

On 1/17/16 11:28 PM, Rahul Singh wrote:
> Code flow is attached, forgot to attach in trailing mail.
>
> ------
- --
>
>
*From:* Rahul Singh 
> *Sent:* Monday, January 18, 2016 8:39 AM *To:* Tomcat Users List
> *Subject:* Re: File size >= 2GB not uploaded in application
> [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]
>
> Hello Christopher, thanks for your prompt response !!
>
>> Why didn't you come to the Tomcat community first?
> Sorry for the delay, we wanted to make sure about the component
> causing the problem.
>
>
>>> I don't have a test-case in front of me, but I'm fairly
>>> confident that Tomcat allows file uploads of greater than 2GiB.
>>> I suspect the problem
> is another component.
>>> Are you using Servlet 3.0-based file upload, or are you
>>> allowing Struts to handle the file-upload for you? If you use
>>> Servlet-3.0 file-upload, then you'll have code that deals with
>>> Multipart classes and configuration in web.xml. If you are
>>> using Struts's file-upload, then you'll mostly just be calling
>>> getFile or getInputStream or however Struts 2 does things (I
>>> can't remember how it all works off the top of my head).
>
>
> In our case the filter class implements the javax.servlet.flter
> and imports javax.servlet.* The Filter class mentioned in the
> previous threads is the first one as declared in the web.xml
> (followed by other struts filters). All (url) requests are mapped
> to this filter. So this is where our file upload request goes. It
> is only in greater than 2 gb file upload request that the
> dofilter() fails to get any request. So we feel servlet 3.0 being
> used in our case the Filter is not being able to handle greater
> than 2 gb requests.
>
>
>>> The point is, if you are using Struts, then Tomcat will not
>>> touch the request and Struts is handling the whole thing. If
>>> Struts is the problem, you'll need to talk to the Struts
>>> team[1].
>
>>> If you are using Servlet-3.0 file-upload, then Struts is just a
>>> red herring and this is the right place to get your issue
>>> solved.
>
> As mentioned above Servlet 3.0 is being used. So request the
> tomcat community to please look into our issue.
>
>>> So far, you have posted some configuration for Struts and some
>>> JSP tablib-filled code, plus some Java code for a Filter. You
>>> didn't say where the Filter was in the filter chain (before or
>>> after Struts filter). You also mentioned that the form is
>>> actually posted using XMLHttpRequest and not through a standard
>>> form, but you didn't explain what component is doing that or
>>> how it actually works.
>
>>> There isn't enough information here to make any sense of the
>>> situation. Can you please address all of the questions I've
>>> posed above and maybe we can then help you?
>
>
> <<>>> We need to model the fol

Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]

[Rahul Singh]

Hi Christopher ,


>>So... what makes you sure that the browser actually made the request?
>>I'd like to see some kind of confirmation using a tool you didn't
>>write. Perhaps something like Firebug, LiveHttpHeaders, Fiddler, or
>>even Wireshark showing that the request was made, what headers it had,
>>etc.

OK,
We have used HTTP Analayzer for file upload via Internet Explorer-8. Following 
are the scenario observed.

For lesser than 2gb file uploads : The request header shows the correct 
content-length value of the file.The uploads works fine further also.

For more than 2gb file uploads: The file length is 2151533567 bytes(which is 
roughly 2.15 Gb).  The request is aborted in this case and the request header 
shows the content length 
as -214343325 bytes (which is rougly 214 Mb).The upload process does not 
proceed further in this case.

both cases request headers are attached in screenshot.

From: Christopher Schultz 
Sent: Monday, January 18, 2016 11:17 AM
To: Tomcat Users List
Subject: Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 
Struts: 2.3.24 JAVA: openJDK 1.7.79]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Rahul,

On 1/17/16 11:28 PM, Rahul Singh wrote:
> Code flow is attached, forgot to attach in trailing mail.
>
> ------
- --
>
>
*From:* Rahul Singh 
> *Sent:* Monday, January 18, 2016 8:39 AM *To:* Tomcat Users List
> *Subject:* Re: File size >= 2GB not uploaded in application
> [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]
>
> Hello Christopher, thanks for your prompt response !!
>
>> Why didn't you come to the Tomcat community first?
> Sorry for the delay, we wanted to make sure about the component
> causing the problem.
>
>
>>> I don't have a test-case in front of me, but I'm fairly
>>> confident that Tomcat allows file uploads of greater than 2GiB.
>>> I suspect the problem
> is another component.
>>> Are you using Servlet 3.0-based file upload, or are you
>>> allowing Struts to handle the file-upload for you? If you use
>>> Servlet-3.0 file-upload, then you'll have code that deals with
>>> Multipart classes and configuration in web.xml. If you are
>>> using Struts's file-upload, then you'll mostly just be calling
>>> getFile or getInputStream or however Struts 2 does things (I
>>> can't remember how it all works off the top of my head).
>
>
> In our case the filter class implements the javax.servlet.flter
> and imports javax.servlet.* The Filter class mentioned in the
> previous threads is the first one as declared in the web.xml
> (followed by other struts filters). All (url) requests are mapped
> to this filter. So this is where our file upload request goes. It
> is only in greater than 2 gb file upload request that the
> dofilter() fails to get any request. So we feel servlet 3.0 being
> used in our case the Filter is not being able to handle greater
> than 2 gb requests.
>
>
>>> The point is, if you are using Struts, then Tomcat will not
>>> touch the request and Struts is handling the whole thing. If
>>> Struts is the problem, you'll need to talk to the Struts
>>> team[1].
>
>>> If you are using Servlet-3.0 file-upload, then Struts is just a
>>> red herring and this is the right place to get your issue
>>> solved.
>
> As mentioned above Servlet 3.0 is being used. So request the
> tomcat community to please look into our issue.
>
>>> So far, you have posted some configuration for Struts and some
>>> JSP tablib-filled code, plus some Java code for a Filter. You
>>> didn't say where the Filter was in the filter chain (before or
>>> after Struts filter). You also mentioned that the form is
>>> actually posted using XMLHttpRequest and not through a standard
>>> form, but you didn't explain what component is doing that or
>>> how it actually works.
>
>>> There isn't enough information here to make any sense of the
>>> situation. Can you please address all of the questions I've
>>> posed above and maybe we can then help you?
>
>
> <<>>> We need to model the following code to be told:
> jsp submit of the form How the .js submit it further in
> XmlHttpRequest How the Filter is declared How the web.xml is
> declared
>
>
>> Are you sure the request is even made to the server in these
>> cases?What if the Javascript upload component is failing before
>> it even starts?
>
> Yes the request is made in these cases. We have compared the
> scenario 

Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]

[Rahul Singh]

Code flow is attached, forgot to attach in trailing mail.



From: Rahul Singh 
Sent: Monday, January 18, 2016 8:39 AM
To: Tomcat Users List
Subject: Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 
Struts: 2.3.24 JAVA: openJDK 1.7.79]

Hello Christopher,
thanks for your prompt response !!

> Why didn't you come to the Tomcat community first?
Sorry for the delay, we wanted to make sure about the component causing the 
problem.


>>I don't have a test-case in front of me, but I'm fairly confident that
>>Tomcat allows file uploads of greater than 2GiB. I suspect the problem
is another component.
>>Are you using Servlet 3.0-based file upload, or are you allowing
>>Struts to handle the file-upload for you? If you use Servlet-3.0
>>file-upload, then you'll have code that deals with Multipart classes
>>and configuration in web.xml. If you are using Struts's file-upload,
>>then you'll mostly just be calling getFile or getInputStream or
>>however Struts 2 does things (I can't remember how it all works off
>>the top of my head).


In our case the filter class implements the javax.servlet.flter and imports 
javax.servlet.*
The Filter class mentioned in the previous threads is the first one as declared 
in the web.xml (followed by other struts filters).
 All (url) requests are mapped to this filter. So this is where our file upload 
request goes. It is only in greater than 2 gb file upload request that the 
dofilter() fails to get any request.
So we feel servlet 3.0 being used in our case the Filter is not being able to 
handle greater than 2 gb requests.


>>The point is, if you are using Struts, then Tomcat will not touch the
>>request and Struts is handling the whole thing. If Struts is the
>>problem, you'll need to talk to the Struts team[1].

>>If you are using Servlet-3.0 file-upload, then Struts is just a red
>>herring and this is the right place to get your issue solved.

As mentioned above Servlet 3.0 is being used. So request the tomcat community 
to please look into our issue.

>>So far, you have posted some configuration for Struts and some JSP
>>tablib-filled code, plus some Java code for a Filter. You didn't say
>>where the Filter was in the filter chain (before or after Struts
>>filter). You also mentioned that the form is actually posted using
>>XMLHttpRequest and not through a standard form, but you didn't explain
>>what component is doing that or how it actually works.

>>There isn't enough information here to make any sense of the
>>situation. Can you please address all of the questions I've posed
>>above and maybe we can then help you?


<<>>> We need to model the following code to be told:
 jsp submit of the form
How the .js submit it further in XmlHttpRequest
How the Filter is declared
How the web.xml is declared


>Are you sure the request is even made to the server in these cases?What if the 
>Javascript upload component is failing before it even starts?

Yes the request is made in these cases. We have compared the scenario for 
greater than 2gb and lesser size file uploads and drawn the following inference 
from it.We have checked the request and content length for dofilter() method in 
our logs. The JavaScript is not the culprit in this case. The JavaScript sets 
the AJAX field to success after sending request and thereafter waits for 
response(which is not received in our case). Our application works fine for 
lesser than 2 gb fie uploads but fails for greater size files as the request 
fails to reach the dofilter() method after which the request can be forwarded 
to the requested method.



Regards,
Rahul


From: Christopher Schultz 
Sent: Saturday, January 16, 2016 9:33 AM
To: Tomcat Users List
Subject: Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 
Struts: 2.3.24 JAVA: openJDK 1.7.79]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Rahul,

On 1/15/16 1:02 AM, Rahul Singh wrote:
> Thanks for your guidelines, we have big hope from Apache Tomcat
> Team to solve this problem as this is show stopper for our
> application, we have also raise this question on various forum like
> stack overflow and other, but no relevant reply till now.

Why didn't you come to the Tomcat community first?

> Hope you understand my situation,
>
> please refer the below stackoverflow reference for more detail
> about this issue.
>
> http://stackoverflow.com/questions/34783438/dofilter-fails-to-get-any-
[http://cdn.sstatic.net/stackoverflow/img/apple-touch-i...@2.png?v=73d79a89bded&a]<http://stackoverflow.com/questions/34783438/dofilter-fails-to-get-any->

doFilter() fails to get any request for the file upload > 
2gb<http://st

Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]

[Rahul Singh]

Hello Christopher,
thanks for your prompt response !!

> Why didn't you come to the Tomcat community first?
Sorry for the delay, we wanted to make sure about the component causing the 
problem.


>>I don't have a test-case in front of me, but I'm fairly confident that
>>Tomcat allows file uploads of greater than 2GiB. I suspect the problem
is another component.
>>Are you using Servlet 3.0-based file upload, or are you allowing
>>Struts to handle the file-upload for you? If you use Servlet-3.0
>>file-upload, then you'll have code that deals with Multipart classes
>>and configuration in web.xml. If you are using Struts's file-upload,
>>then you'll mostly just be calling getFile or getInputStream or
>>however Struts 2 does things (I can't remember how it all works off
>>the top of my head).


In our case the filter class implements the javax.servlet.flter and imports 
javax.servlet.* 
The Filter class mentioned in the previous threads is the first one as declared 
in the web.xml (followed by other struts filters).
 All (url) requests are mapped to this filter. So this is where our file upload 
request goes. It is only in greater than 2 gb file upload request that the 
dofilter() fails to get any request.
So we feel servlet 3.0 being used in our case the Filter is not being able to 
handle greater than 2 gb requests.


>>The point is, if you are using Struts, then Tomcat will not touch the
>>request and Struts is handling the whole thing. If Struts is the
>>problem, you'll need to talk to the Struts team[1].

>>If you are using Servlet-3.0 file-upload, then Struts is just a red
>>herring and this is the right place to get your issue solved.

As mentioned above Servlet 3.0 is being used. So request the tomcat community 
to please look into our issue.

>>So far, you have posted some configuration for Struts and some JSP
>>tablib-filled code, plus some Java code for a Filter. You didn't say
>>where the Filter was in the filter chain (before or after Struts
>>filter). You also mentioned that the form is actually posted using
>>XMLHttpRequest and not through a standard form, but you didn't explain
>>what component is doing that or how it actually works.

>>There isn't enough information here to make any sense of the
>>situation. Can you please address all of the questions I've posed
>>above and maybe we can then help you?


<<>>> We need to model the following code to be told: 
 jsp submit of the form
How the .js submit it further in XmlHttpRequest
How the Filter is declared 
How the web.xml is declared


>Are you sure the request is even made to the server in these cases?What if the 
>Javascript upload component is failing before it even starts?

Yes the request is made in these cases. We have compared the scenario for 
greater than 2gb and lesser size file uploads and drawn the following inference 
from it.We have checked the request and content length for dofilter() method in 
our logs. The JavaScript is not the culprit in this case. The JavaScript sets 
the AJAX field to success after sending request and thereafter waits for 
response(which is not received in our case). Our application works fine for 
lesser than 2 gb fie uploads but fails for greater size files as the request 
fails to reach the dofilter() method after which the request can be forwarded 
to the requested method.



Regards,
Rahul 


From: Christopher Schultz 
Sent: Saturday, January 16, 2016 9:33 AM
To: Tomcat Users List
Subject: Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 
Struts: 2.3.24 JAVA: openJDK 1.7.79]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Rahul,

On 1/15/16 1:02 AM, Rahul Singh wrote:
> Thanks for your guidelines, we have big hope from Apache Tomcat
> Team to solve this problem as this is show stopper for our
> application, we have also raise this question on various forum like
> stack overflow and other, but no relevant reply till now.

Why didn't you come to the Tomcat community first?

> Hope you understand my situation,
>
> please refer the below stackoverflow reference for more detail
> about this issue.
>
> http://stackoverflow.com/questions/34783438/dofilter-fails-to-get-any-
request-for-the-file-upload-2gb?noredirect=1#comment57315528_34783438
>
>
>
for more information:
>
> -No error are printed in tomcat logs. - how to configure "call
> HttpServletRequest.getHeader("Content-Length") as a String and
> parse it yourself."

I don't have a test-case in front of my, but I'm fairly confident that
Tomcat allows file uploads of greater than 2GiB. I suspect the problem
is another component.

Are you using Servlet 3.0-based file upload, or are you allowing
St

Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]

[Rahul Singh]

Dear Christopher,

Thanks for your guidelines, we have big hope from Apache Tomcat Team to solve 
this problem as this is show stopper for our application, we have also raise 
this question on various forum like stack overflow and other,but no relevant 
reply till now.

Hope you understand my situation,

please refer the below stackoverflow reference for more detail about this 
issue. 

http://stackoverflow.com/questions/34783438/dofilter-fails-to-get-any-request-for-the-file-upload-2gb?noredirect=1#comment57315528_34783438


for more information:

 -No error are printed in tomcat logs.
- how to configure "call HttpServletRequest.getHeader("Content-Length") as a 
String and parse it yourself."







From: Christopher Schultz 
Sent: Thursday, January 14, 2016 8:43 PM
To: Tomcat Users List
Subject: Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 
Struts: 2.3.24 JAVA: openJDK 1.7.79]

André,

On 1/14/16 5:02 AM, André Warnier (tomcat) wrote:
> I have not followed this thread in details, but did you check this :
>
> http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Common_Attributes
> --> maxPostSize

+1

> The maximum size in bytes of the POST which will be handled by the
> container FORM URL parameter parsing. The limit can be disabled by
> setting this attribute to a value less than zero. If not specified, this
> attribute is set to 2097152 (2 megabytes). Note that the
> FailedRequestFilter can be used to reject requests that exceed this limit.
>
> Note: the size above might relate to the *encoded* size of the file, as
> it is transmitted over the WWW (possibly encoded as Base64 e.g.), which
> may mean that an original 1 MB file translates to more than 1 MB bytes
> while being uploaded.
>
> Note also : maybe "Struts" is setting this to some other default value..
>
> Another question : did you check the Tomcat logs ?

IIRC, Tomcat doesn't log anything in these cases. You have to use the
FailedRequestFilter to detect and report the condition. I wouldn't use
that Filter in productio, but it would be good as a simple test to see
if this is the error that is occurring.

When Tomcat refuses to allow a file upload that it too large, it simply
does not parse the parameters, but the request continues to process as
usual (but the servlet doesn't end up getting any of the parameters).
I'm surprised that Struts isn't getting the request in these cases.

-chris

-
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

Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]

[Rahul Singh]

Hello Christopher ,
Thanks for your input,



>ServletRequest.getContentLength is declared to return an int value (32-bit):

>* Integer.MAX_VALUE  = 2^31 - 1 = 2147483647
>* 2GiB = 2 * 1024 * 1024 * 1024 = 2147483648
>* 2147483648 > 2147483647

>Therefore, request.getContentLength cannot be used to fetch
>content-lengths over 2GiB - 1byte.

Yes above is already investigated, BTW thanks .

 You have to use
>ServletRequest.getContentLengthLong (new in servlet 3.1)

for this we have to upgrade tomcat 8, currently we are using tomcat 7.0.54.

> or call
>HttpServletRequest.getHeader("Content-Length") as a String and parse it
>yourself.

OK, but where we need to do this, in init() method or in doFilter() method, but 
FYI, the request(upload file >2GB) is not reached to doFilter().


Apart from above thread we want to share more information so that tomcat team 
help us to get out from this issue.

For my struts project the doFilter() fails to get any request from the file 
upload form in cases the size of the file is greater than 2gb. 
Below is the code fragment:

Filter is as follows:

public void doFilter(ServletRequest req, ServletResponse res, FilterChain 
chain) throws IOException, ServletException
{   
HttpServletRequest request = (HttpServletRequest) req;
HttpServletResponse response = (HttpServletResponse) res;
HttpSession session = request.getSession(false);
request.setCharacterEncoding("UTF-8");

/*
do the other business work example request response monitoring and 
logging
*/

 chain.doFilter(request, response);  

}

jsp is :



For my jsp the form is submitted as a XMLHttpRequest via the underlying 
javascipt. 
Now when I upload a a file (lesser than 2gb) ,in my dofilter() method I have 
checked the uri and request length for the request.
They are as expected via the action called in the jsp form and the file size.
The file upload works fine in this case. But in case where the file size is 
greater than 2gb ,
in my doFilter() method no request is available for the file upload action 
called by the form submit(for file size greater than 2 gb). 
Thus the upload does not proceed further in such cases.

I am using servlet 3.0. 
What do I need to do to support larger than 2 gb file uploads, so that the 
request reaches the doFilter() method?




From: Christopher Schultz 
Sent: Wednesday, January 13, 2016 8:11 PM
To: Tomcat Users List
Subject: Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 
Struts: 2.3.24 JAVA: openJDK 1.7.79]

Rahul,

On 1/12/16 10:56 PM, Rahul Singh wrote:
> Hi,
>
>> Define "Not successful"?  Exceptions thrown?  File truncated?  Upload
>> never starts?  Never finishes?
>
> Not successful :
>
> Request Never finishes, we have trace the HttpServlet request object
> and request.getContentLength return 0 in case when file size is >=2GB,
>
> No exception thrown, as well as when file size is less than 2GB, then
> request.getContentLength return the correct value of file size in
> byte.

ServletRequest.getContentLength is declared to return an int value (32-bit):

* Integer.MAX_VALUE  = 2^31 - 1 = 2147483647
* 2GiB = 2 * 1024 * 1024 * 1024 = 2147483648
* 2147483648 > 2147483647

Therefore, request.getContentLength cannot be used to fetch
content-lengths over 2GiB - 1byte. You have to use
ServletRequest.getContentLengthLong (new in servlet 3.1) or call
HttpServletRequest.getHeader("Content-Length") as a String and parse it
yourself.

-chris

-
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

Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]

[Rahul Singh]

Hi André Warnier,

its 64 bit (OS and JVM)


From: André Warnier (tomcat) 
Sent: Wednesday, January 13, 2016 2:17 PM
To: users@tomcat.apache.org
Subject: Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 
Struts: 2.3.24 JAVA: openJDK 1.7.79]

maybe a stupid question nowadays, but : is the platform on which you are 
running this
32-bit, or 64-bit ? (OS and JVM)

On 13.01.2016 04:56, Rahul Singh wrote:
> Hi,
>
>> Define "Not successful"?  Exceptions thrown?  File truncated?  Upload
>> never starts?  Never finishes?
>
> Not successful :
>
> Request Never finishes, we have trace the HttpServlet request object and 
> request.getContentLength return 0 in case when file size is >=2GB,
>
> No exception thrown, as well as when file size is less than 2GB, then 
> request.getContentLength return the correct value of file size in byte.
>
>
> Regards,
> Rahul Kumar Singh
> 
> From: David kerber 
> Sent: Tuesday, January 12, 2016 6:07 PM
> To: Tomcat Users List
> Subject: Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 
> Struts: 2.3.24 JAVA: openJDK 1.7.79]
>
> On 1/12/2016 12:01 AM, Rahul Singh wrote:
>>
>> Hello Apache Tomcat team,
>>
>> Sending again with some corrections,
>>
>> File upload in my  application(Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 
>> 1.7.79) is not successful for greater than 2 gb. After previous discussion 
>> here on previous thread, I migrated my application to struts 2.3.24 as the 
>> only possible solution in form of jakarta-stream parser for large size 
>> uploads (greater than 2gb).
>> But after successfully migrating to struts 2.3.24 from 2.1.8, file upload 
>> greater than 2 gb still not supported. I want to use jakarta-streams for 
>> this purpose.Following is the code
>> snippet:
>>
>>
>> In struts.xml:
>> 
>>
>> 
>> 
>>
>> In JSP:
>> ===
>>
>> > namespace="xyz"   validateFields="false" method="post"
>> enctype="multipart/form-data">
>>
>>
>> Alongwith with configuring server.xml with maxPostSize element and 
>> mutipart-config in web.xml But still the file upload request for greater 
>> than 2 gb not successful. 
>
> Define "Not successful"?  Exceptions thrown?  File truncated?  Upload
> never starts?  Never finishes?
>
>
> -
> 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

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]

[Rahul Singh]

Hi,

>Define "Not successful"?  Exceptions thrown?  File truncated?  Upload
>never starts?  Never finishes?

Not successful :

Request Never finishes, we have trace the HttpServlet request object and 
request.getContentLength return 0 in case when file size is >=2GB,

No exception thrown, as well as when file size is less than 2GB, then 
request.getContentLength return the correct value of file size in byte.


Regards,
Rahul Kumar Singh

From: David kerber 
Sent: Tuesday, January 12, 2016 6:07 PM
To: Tomcat Users List
Subject: Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 
Struts: 2.3.24 JAVA: openJDK 1.7.79]

On 1/12/2016 12:01 AM, Rahul Singh wrote:
>
> Hello Apache Tomcat team,
>
> Sending again with some corrections,
>
> File upload in my  application(Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 
> 1.7.79) is not successful for greater than 2 gb. After previous discussion 
> here on previous thread, I migrated my application to struts 2.3.24 as the 
> only possible solution in form of jakarta-stream parser for large size 
> uploads (greater than 2gb).
> But after successfully migrating to struts 2.3.24 from 2.1.8, file upload 
> greater than 2 gb still not supported. I want to use jakarta-streams for this 
> purpose.Following is the code
> snippet:
>
>
> In struts.xml:
> 
>
> 
> 
>
> In JSP:
> ===
>
>  namespace="xyz"   validateFields="false" method="post"
> enctype="multipart/form-data">
>
>
> Alongwith with configuring server.xml with maxPostSize element and 
> mutipart-config in web.xml But still the file upload request for greater than 
> 2 gb not successful. 

Define "Not successful"?  Exceptions thrown?  File truncated?  Upload
never starts?  Never finishes?


-
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

Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]

[Rahul Singh]

Hello Apache Tomcat team,

Sending again with some corrections,

File upload in my  application(Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 
1.7.79) is not successful for greater than 2 gb. After previous discussion here 
on previous thread, I migrated my application to struts 2.3.24 as the only 
possible solution in form of jakarta-stream parser for large size uploads 
(greater than 2gb).
But after successfully migrating to struts 2.3.24 from 2.1.8, file upload 
greater than 2 gb still not supported. I want to use jakarta-streams for this 
purpose.Following is the code
snippet:


In struts.xml:





In JSP:
===




Alongwith with configuring server.xml with maxPostSize element and 
mutipart-config in web.xml But still the file upload request for greater than 2 
gb not successful. 


Thanks
Rahul


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]

[Rahul Singh]

Hello Apache Tomcat team,


File upload in my  application(Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 
1.7.79) is not successful for greater than 2 gb. After previous
discussion here on previous thread, I migrated my application to struts 2.3.24 
as the only
possible solution in form of jakarta-stream parser for large size uploads 
(greater than 2gb).
But after successfully migrating to struts 2.3.24 from 2.1.8, file upload 
greater than 2 gb
still not supported. I want to use jakarta-streams for this purpose.Following 
is the code
snippet:
In struts.xml: 
jsp file:

Alongwith with configuring server.xml with maxPostSize element and 
mutipart-config in web.xml
But still the file upload request for greater than 2 gb not successful. 


Thanks
Rahul

RE: logjam attacks in tomcat 7

[Rahul Singh]

Ok Thanks for your quick response.Could you please tell me the size of cipher 
key mentioned below is it stronger than 
1024?ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,SSL_RSA_WITH_RC4_128_SHA"
> Subject: Re: logjam attacks in tomcat 7
> To: users@tomcat.apache.org
> From: ma...@apache.org
> Date: Thu, 1 Oct 2015 08:59:31 +0200
> 
> On 01/10/2015 07:08, Rahul Singh wrote:
> > Yes i know this fix,
> > i just want to know, waht is deafult cipher deatil, in my existing 
> > server.xml no cipher parameter value is mentioned.So please help me to 
> > understand the same.
> 
> To quote the documentation:
> 
> 
> By default, the default ciphers for the JVM will be used. Note that this
> usually means that the weak export grade ciphers will be included in the
> list of available ciphers.
> 
> 
> If you want to know what that means for the JVM you are using then I
> strongly recommend this site:
> 
> https://www.ssllabs.com/ssltest/
> 
> Mark
> 
> 
> > 
> > 
> > 
> > 
> >> Date: Thu, 1 Oct 2015 10:26:43 +0530
> >> Subject: Re: logjam attacks in tomcat 7
> >> From: srikanth.hu...@gmail.com
> >> To: users@tomcat.apache.org
> >>
> >> Configuration like mentioned below should be able to resolve your issue:
> >>
> >>  >> protocol="org.apache.coyote.http11.Http11Protocol" SSLEnabled="true"
> >>maxThreads="150" scheme="https" secure="true"
> >>keystoreType="JKS" keystoreFile="{{path_to_keystore}}"
> >> keystorePass="{{ keystore_password }}"
> >>clientAuth="false" sslEnabledProtocols="TLSv1, TLSv1.1,
> >> TLSv1.2"
> >>  
> >> ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
> >>  
> >> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_RC4_128_SHA,
> >>  
> >> TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,
> >>  TLS_RSA_WITH_AES_256_CBC_SHA,SSL_RSA_WITH_RC4_128_SHA" />
> >>
> >> Srikanth Hugar
> >> www.gharki.com
> >>
> >>
> >>
> >> On Thu, Oct 1, 2015 at 10:22 AM, Rahul Singh  wrote:
> >>
> >>> Dear Tomcat Support Team,Thanks for your continuous support.
> >>> In our Application Tomcat V 7.0.54 is used. We are facing the problem of
> >>> "Server has a weak, ephemeral Diffie-Hellman public key
> >>> ERR_SSL_WEAK_SERVER_EPHEMERAL_DH_KEY"
> >>> In chrome browser.
> >>> Tomcat server .xml have following configuration, which does not contain
> >>> chipher, it means it used default cipher.
> >>>  >>> port="8585" minSpareThreads="5"enableLookups="true"
> >>> redirectPort="8282"acceptCount="32"
> >>> connectionTimeout="6"/>  >>> SSLEnabled="true"enableLookups="true"
> >>>   acceptCount="32"  scheme="https" secure="true"
> >>> clientAuth="false" sslEnabledProtocols="TLSv1.2"
> >>>  
> >>> algorithm="SunX509"/>
> >>> Underline JAVA is : OpenJDK Runtime Environment (rhel-2.5.5.3.el6-x86_64
> >>> u79-b14)
> >>> So could ypu please assist me to understand the following things.
> >>> 1- What value of default cipher is using in My application.2- Does it
> >>> require to update for working with lates Browser chrome and fixing the
> >>> "Diffie-Hellman" security issue.
> >>> Regards,Rahul kumar Singh
> >   
> > 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
  

RE: logjam attacks in tomcat 7

[Rahul Singh]

Yes i know this fix,
i just want to know, waht is deafult cipher deatil, in my existing server.xml 
no cipher parameter value is mentioned.So please help me to understand the same.




> Date: Thu, 1 Oct 2015 10:26:43 +0530
> Subject: Re: logjam attacks in tomcat 7
> From: srikanth.hu...@gmail.com
> To: users@tomcat.apache.org
> 
> Configuration like mentioned below should be able to resolve your issue:
> 
>  protocol="org.apache.coyote.http11.Http11Protocol" SSLEnabled="true"
>maxThreads="150" scheme="https" secure="true"
>keystoreType="JKS" keystoreFile="{{path_to_keystore}}"
> keystorePass="{{ keystore_password }}"
>clientAuth="false" sslEnabledProtocols="TLSv1, TLSv1.1,
> TLSv1.2"
>  
> ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
>  
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_RC4_128_SHA,
>  
> TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,
>  TLS_RSA_WITH_AES_256_CBC_SHA,SSL_RSA_WITH_RC4_128_SHA" />
> 
> Srikanth Hugar
> www.gharki.com
> 
> 
> 
> On Thu, Oct 1, 2015 at 10:22 AM, Rahul Singh  wrote:
> 
> > Dear Tomcat Support Team,Thanks for your continuous support.
> > In our Application Tomcat V 7.0.54 is used. We are facing the problem of
> > "Server has a weak, ephemeral Diffie-Hellman public key
> > ERR_SSL_WEAK_SERVER_EPHEMERAL_DH_KEY"
> > In chrome browser.
> > Tomcat server .xml have following configuration, which does not contain
> > chipher, it means it used default cipher.
> >  > port="8585" minSpareThreads="5"enableLookups="true"
> > redirectPort="8282"acceptCount="32"
> > connectionTimeout="6"/>  > SSLEnabled="true"enableLookups="true"
> >   acceptCount="32"  scheme="https" secure="true"
> > clientAuth="false" sslEnabledProtocols="TLSv1.2"
> >  
> > algorithm="SunX509"/>
> > Underline JAVA is : OpenJDK Runtime Environment (rhel-2.5.5.3.el6-x86_64
> > u79-b14)
> > So could ypu please assist me to understand the following things.
> > 1- What value of default cipher is using in My application.2- Does it
> > require to update for working with lates Browser chrome and fixing the
> > "Diffie-Hellman" security issue.
> > Regards,Rahul kumar Singh
  

logjam attacks in tomcat 7

[Rahul Singh]

Dear Tomcat Support Team,Thanks for your continuous support.
In our Application Tomcat V 7.0.54 is used. We are facing the problem of 
"Server has a weak, ephemeral Diffie-Hellman public key 
ERR_SSL_WEAK_SERVER_EPHEMERAL_DH_KEY"
In chrome browser.
Tomcat server .xml have following configuration, which does not contain 
chipher, it means it used default cipher.
 
Underline JAVA is : OpenJDK Runtime Environment (rhel-2.5.5.3.el6-x86_64 
u79-b14)
So could ypu please assist me to understand the following things.
1- What value of default cipher is using in My application.2- Does it require 
to update for working with lates Browser chrome and fixing the "Diffie-Hellman" 
security issue.
Regards,Rahul kumar Singh 

log4j:ERROR setFile(null,true) call failed.

[Rahul Singh]

Dear Tomcat team,thanks for your continuous support.
please assist us to find the root cause of the below problem.
during the start of tomcat server, the below error occurred. 

Jul 30, 2015 6:57:38 AM org.apache.coyote.AbstractProtocol initINFO: 
Initializing ProtocolHandler ["http-bio-8585"]Jul 30, 2015 6:57:38 AM 
org.apache.coyote.AbstractProtocol initINFO: Initializing ProtocolHandler 
["http-bio-8282"]Jul 30, 2015 6:57:39 AM org.apache.catalina.startup.Catalina 
loadINFO: Initialization processed in 1601 msJul 30, 2015 6:57:39 AM 
org.apache.catalina.core.StandardService startInternalINFO: Starting service 
CatalinaJul 30, 2015 6:57:39 AM org.apache.catalina.core.StandardEngine 
startInternalINFO: Starting Servlet Engine: Apache Tomcat Serverlog4j:ERROR 
setFile(null,true) call failed.java.io.FileNotFoundException: 
/var/log/HYDRAstor/hydragui/hydragui.log (Permission denied)at 
java.io.FileOutputStream.open(Native Method)at 
java.io.FileOutputStream.(FileOutputStream.java:221)at 
java.io.FileOutputStream.(FileOutputStream.java:142)at 
org.apache.log4j.FileAppender.setFile(FileAppender.java:290)at 
org.apache.log4j.RollingFileAppender.setFile(RollingFileAppender.java:194)  
  at org.apache.log4j.FileAppender.activateOptions(FileAppender.java:164)   
 at org.apache.log4j.config.PropertySetter.activate(PropertySetter.java:257)
at 
org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:133)   
 at 
org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:97)
at 
org.apache.log4j.PropertyConfigurator.parseAppender(PropertyConfigurator.java:689)
at 
org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:647)
at 
org.apache.log4j.PropertyConfigurator.configureRootCategory(PropertyConfigurator.java:544)
at 
org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:440)
at 
org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:476)
at 
org.apache.log4j.helpers.OptionConverter.selectAndConfigure(OptionConverter.java:471)
at org.apache.log4j.LogManager.(LogManager.java:125)at 
org.apache.log4j.Logger.getLogger(Logger.java:105)at 
org.apache.commons.logging.impl.Log4JLogger.getLogger(Log4JLogger.java:283) 
   at org.apache.commons.logging.impl.Log4JLogger.(Log4JLogger.java:108)  
  at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)  
  at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)  
  at 
org.apache.commons.logging.impl.LogFactoryImpl.createLogFromClass(LogFactoryImpl.java:1040)
at 
org.apache.commons.logging.impl.LogFactoryImpl.discoverLogImplementation(LogFactoryImpl.java:838)
at 
org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:601)
at 
org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:333)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:664)
at org.apache.commons.digester.Digester.(Digester.java:303)at 
com.nec.hydragui.model2.biz.framework.menu.MenuFactory.parse(MenuFactory.java:88)
at 
com.nec.hydragui.model2.biz.framework.menu.MenuFactory.init(MenuFactory.java:72)
at 
com.nec.hydragui.utils.HydraServletContextListener.parseMenuConfig(HydraServletContextListener.java:84)
at 
com.nec.hydragui.utils.HydraServletContextListener.contextInitialized(HydraServletContextListener.java:39)
at 
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4973)
at 
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5467)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) 
   at 
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1559) 
   at 
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1549) 
   at java.util.concurrent.FutureTask.run(FutureTask.java:262)at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) 
   at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
   at java.lang.Thread.run(Thread.java:745)log4j:ERROR setFile(null,true) 
call failed.