Re: Application throwing ClassCast Exception while upgrading from tomcat 8.0.18 to tomcat 8.0.30

[Adhavan Mathiyalagan]

Thanks for your answer Konstantin !.

I will re-verify the code.

Adhavan.M



On Sat, Jan 30, 2016 at 5:56 PM, Konstantin Kolinko 
wrote:

> 2016-01-20 1:47 GMT+03:00 Mark Thomas :
> > On 19/01/2016 16:37, Adhavan Mathiyalagan wrote:
> >> Thanks Mark ! Please find my answer
> >>
> >> Figure out what is inserting something other than String[] as the value
> >> into a Map instance.
> >>
> >> There are lot of places in Client we insert 'Integer' datatype (Also
> >> other datatypes) .I fear that it is going to be more
> >> tedious thing to identify and fix all the client code.
> >>
> >>  Is there any other way or path forward to fix this ? (Like upgrading
> the
> >> displaytag version
> >> which is currently 1.1)  Or Is the modifying the Client Code is the only
> >> path forward ?
> >
> > It depends. How are you inserting Integers into that Map? I'm trying to
> > figure out if this is a client code bug or if the restriction that was
> > added to Tomcat was overly strict and needs to be reverted.
> >
>
> Looking for DisplayTag 1.1 source jar at Maven Central,  it is a
> rather old library.  The latest version is 1.2 (released in 2008).
>
> 1.1 was released in 2006.  Why OP haven't upgraded to 1.2 ?
>
> Web site:
> http://www.displaytag.org/
> http://sourceforge.net/projects/displaytag/
>
> That said, I do not see any obvious errors in that library. It creates
> a copy of parameter map (DefaultRequestHelper.getParameterMap()). I do
> not see it inserting any values into original map. I also do not see
> it implementing a ServletRequestWrapper.
>
> So I think the error is not in the library, but in some other code.
>
>
> I think the Tomcat code is OK.
>
> The official Servlet Specification javadoc says that the values in
> ParameterMap are String[], and this requirement has to be enforced at
> some point of time. Looking into Servlet 2.4 Javadoc (the spec
> released in 2003, implemented by Tomcat 5.x) it says exactly the same.
> [1][2] So a library released in year 2006 must follow it.
>
>
> Regarding a technical way to insert incorrect parameters. In theory I
> see two ways:
>
> 1. org.apache.catalina.core.ApplicationHttpRequest is a wrapper. The
> wrapped request may be beyond our control, but it still has to follow
> the spec.
>
> 2. The map returned by ApplicationHttpRequest class must be immutable
> [2], but it is not enforced. I filed
> https://bz.apache.org/bugzilla/show_bug.cgi?id=58946
>
>
> [1]
> https://wiki.apache.org/tomcat/Specifications#Java_Servlet_Specifications
> [2]
> http://docs.oracle.com/javaee/1.4/api/javax/servlet/ServletRequest.html#getParameterMap%28%29
>
> Best regards,
> Konstantin Kolinko
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Application throwing ClassCast Exception while upgrading from tomcat 8.0.18 to tomcat 8.0.30

[Konstantin Kolinko]

2016-01-20 1:47 GMT+03:00 Mark Thomas :
> On 19/01/2016 16:37, Adhavan Mathiyalagan wrote:
>> Thanks Mark ! Please find my answer
>>
>> Figure out what is inserting something other than String[] as the value
>> into a Map instance.
>>
>> There are lot of places in Client we insert 'Integer' datatype (Also
>> other datatypes) .I fear that it is going to be more
>> tedious thing to identify and fix all the client code.
>>
>>  Is there any other way or path forward to fix this ? (Like upgrading the
>> displaytag version
>> which is currently 1.1)  Or Is the modifying the Client Code is the only
>> path forward ?
>
> It depends. How are you inserting Integers into that Map? I'm trying to
> figure out if this is a client code bug or if the restriction that was
> added to Tomcat was overly strict and needs to be reverted.
>

Looking for DisplayTag 1.1 source jar at Maven Central,  it is a
rather old library.  The latest version is 1.2 (released in 2008).

1.1 was released in 2006.  Why OP haven't upgraded to 1.2 ?

Web site:
http://www.displaytag.org/
http://sourceforge.net/projects/displaytag/

That said, I do not see any obvious errors in that library. It creates
a copy of parameter map (DefaultRequestHelper.getParameterMap()). I do
not see it inserting any values into original map. I also do not see
it implementing a ServletRequestWrapper.

So I think the error is not in the library, but in some other code.


I think the Tomcat code is OK.

The official Servlet Specification javadoc says that the values in
ParameterMap are String[], and this requirement has to be enforced at
some point of time. Looking into Servlet 2.4 Javadoc (the spec
released in 2003, implemented by Tomcat 5.x) it says exactly the same.
[1][2] So a library released in year 2006 must follow it.


Regarding a technical way to insert incorrect parameters. In theory I
see two ways:

1. org.apache.catalina.core.ApplicationHttpRequest is a wrapper. The
wrapped request may be beyond our control, but it still has to follow
the spec.

2. The map returned by ApplicationHttpRequest class must be immutable
[2], but it is not enforced. I filed
https://bz.apache.org/bugzilla/show_bug.cgi?id=58946


[1] https://wiki.apache.org/tomcat/Specifications#Java_Servlet_Specifications
[2] 
http://docs.oracle.com/javaee/1.4/api/javax/servlet/ServletRequest.html#getParameterMap%28%29

Best regards,
Konstantin Kolinko

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

Re: Tomcat8 startup service exit (return value 143)

[Christian]

Hello all,

On 30.07.2015 18:59, Mark Eggers wrote:
> Here's my current working theory.
>
> As Chris has stated, lots of VM restarts mean that you're probably
> short on entropy. If you're short on entropy, you'll need to wait
> longer for Tomcat to start up.
>
> By default, systemd has a 90 second timeout for starting a unit. If a
> unit doesn't signal a start-up within that time, systemd will shut
> down that service.
>
> You can configure a per-unit start-up time. Do a man 5 systemd.service
> to see how.

I was encountering the same issue as Robert and your working theory sounds 
quite reasonable. I'm in a virtualized
environment, too. In my case it is XenServer and the problem occurs only 
directly after booting. When I manually execute
systemctl start tomcat
everything is fine. That fits to the entropy thing.

In my case it wasn't systemd killing tomcat but jsvc. By default jsvc waits 
only 10 seconds. After configuring
SERVICE_START_WAIT_TIME=90
in setenv.sh, everything is fine now.

Thanks for your heads up.

Regards
Christian

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

Empty xxx_jsp.java files in Tomcat 8.0.26 work catalina directory

[Yasi Xi (yxi)]

Hi, Dear all

I'm doing Tomcat upgrade for my J2EE server.
When Tomcat is upgraded from 7.0.54 to 8.0.26, I get lots of empty *_jsp.java 
files in /opt/apache-tomcat_1/work/Catalina/, for example:

/opt/apache-tomcat_1/work/Catalina/localhost/cmp0307l/org/apache/jsp/webcomponents/jsp/globalpagenotfound_jsp.java

There're six Tomcat servers working in a round-robin manner. Each of the six 
Tomcat server has lots of empty *_jsp.java files, but they do not share the 
same group of empty *_jsp.java files. It appears random regarding which JSP 
file gets an empty *_jsp.java and in which Tomcat server.

When I delete a single empty *_jsp.java file in a Tomcat server and restart 
Tomcat, the previous empty *_jsp.java is generated and not empty.

Has anyone ever got similar situation? Any clue of the root cause?

Appreciate your help!

Regards,
-Yasi

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