RE: Issue found during migration of Tomcat version 6.0.35 to 8.5.5

[John.E.Gregg]

Sorry for the top post.  I'm having email formatting problems.

Lavitesh,

15-Jun-2020 07:34:45.122 SEVERE [http-nio-7080-exec-10] 
org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for 
servlet [MainControllerServlet] in context with path [/porequest] threw 
exception [Servlet execution threw an exception] with root cause
javax.xml.stream.FactoryConfigurationError: Provider 
com.ctc.wstx.stax.WstxInputFactory not found
at javax.xml.stream.XMLInputFactory.newInstance(Unknown Source)

This is saying it can't find WstxInputFactory, which appears to be the Woodstox 
implementation of the XMLInputFactory abstract class.

If you want to continue using Woodstox, you need to add it to your classpath 
again.

If you don't want to use it, there are a few things to check to find out why 
it's being used.  Look for:

-  System property 
javax.xml.stream.XMLInputFactory=com.ctc.wstx.stax.WstxInputFactory

-  $JAVA_HOME/lib/stax.properties

-  $JAVA_HOME/lib/jaxp.properties

-  META-INF/services/javax.xml.stream.XMLInputFactory

That last one is actually a file of the same name as the class.  There is no 
traditional file extension.  This file might also be in a 3rd-party lib, too.  
The file contains the name of the implementation to use.

One of those things is probably telling the finder to use that Woodstox class.

If you don't want to use Woodstox anymore, you have to remove or change one of 
those sources.  Removing it just means you'll get the default.

John



From: Lavitesh Verma 
Sent: Monday, June 15, 2020 8:49 AM
To: Tomcat Users List 
Subject: RE: Issue found during migration of Tomcat version 6.0.35 to 8.5.5


Hi,



PFA the complete Stack Trace for the Issue.

Thanks & Regards
Lavitesh Verma
Software Engineering Associate
Amdocs Global SmartOps
[download12]+91.9810157771
OOO - 06/16 - 06/19
[cid:image001.jpg@01D2912B.17505E90]




-Original Message-

From: Jason Wee mailto:peich...@gmail.com>>

Sent: Monday, June 15, 2020 6:49 PM

To: Tomcat Users List mailto:users@tomcat.apache.org>>

Subject: Re: Issue found during migration of Tomcat version 6.0.35 to 8.5.5



guess looks like jar not found, full stacktrace would be helpful.



On Mon, Jun 15, 2020 at 8:17 PM Lavitesh Verma 
mailto:lavitesh.ve...@amdocs.com>>

wrote:



> Hi Team,

>

>

>

> Below are the details of the system and tomcat version

>

> Old tomcat version: *Apache Tomcat/6.0.35*

>

> New tomcat version: *Apache Tomcat/8.5.5*

>

> Operating System: *SunOS *

>

> OS Version: *5.10*

>

> Architecture: *sparcv9*

>

> JVM Version: *1.8.0_101-b13*

>

> Vendor: *Oracle Corporation*

>

>

>

> We are trying to migrate Apache Tomcat version 6.0.35 to 8.5.5.

>

>

>

> We found the issue javax.xml.stream.FactoryConfigurationError:

> Provider com.ctc.wstx.stax.WstxInputFactory not found in localhost logs.

>

>

>

>

>

> Could you please assist on how we could resolve the issue.

>

>

>

> Thanks & Regards

>

> *Lavitesh Verma*

>

> Software Engineering Associate

>

> Amdocs Global SmartOps

>

> [image: download12]+91.9810157771

>

> *OOO - 06/16 - 06/19*

>

> [image: cid:image001.jpg@01D2912B.17505E90]

>

>

>

> *This email and the information contained herein is proprietary and

> confidential and subject to the Amdocs Email Terms of Service, which

> you may review at*

> *https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww

> .amdocs.com%2Fabout%2Femail-terms-of-service*data=02%7C01%7CLavit

> esh.Verma%40amdocs.com%7Cf5593255a1244392bb8a08d8113145f6%7Cc8eca3ca12

> 7646d59d9da0f2a028920f%7C0%7C0%7C637278250614631760sdata=%2B6rV%2

> Bbnayil4ZJr7yAuCsl2YyE86CZV19JWANZPz%2BIo%3Dreserved=0

>  .amdocs.com%2Fabout%2Femail-terms-of-servicedata=02%7C01%7CLavite

> sh.Verma%40amdocs.com%7Cf5593255a1244392bb8a08d8113145f6%7Cc8eca3ca127

> 646d59d9da0f2a028920f%7C0%7C0%7C637278250614631760sdata=Wtzp%2BGE

> %2BjEvBwZwExHs1jlNLsN5wxGZvYhHK7SAwfxM%3Dreserved=0>

>
This email and the information contained herein is proprietary and confidential 
and subject to the Amdocs Email Terms of Service, which you may review at 
https://www.amdocs.com/about/email-terms-of-service

Re: [OT] [tomcat-users] Issue found during migration of Tomcat version 6.0.35 to 8.5.5

[Lavitesh Verma]

All,



From: Christopher Schultz 
Sent: Tuesday, June 16, 2020, 23:29
To: users@tomcat.apache.org
Subject: Re: [OT] [tomcat-users] Issue found during migration of Tomcat version 
6.0.35 to 8.5.5

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

On 6/15/20 10:02, Jason Pyeron wrote:
> A quick brief on etiquette.
>
> 1.   Please do not harvest emails and send linked in requests

OMG +1 many many times to this.

If I haven't met you in person, don't send me a LinkedIn request.

For that, I have already apologised to Jason (You can certainly connect on that 
with him) but for instance if it had been intentional, we are all technical 
people here and know the value of digital networking.  LinkedIn is such a 
platform for that. Even if i never intended it to be sent to Jason Pyeron but 
to Jason Pryce. It was a bit of a misunderstanding.
> 2.   Do not mark questions as urgent and do provide sufficient
> details to reproduce the problem

I didn't see anything "urgent" about the initial post.

As for the marking urgent post, i had some really pressing need to complete the 
work as i am on leave for the whole week and wanted it to be completed as soon 
as possible. I did not know that marking urgent here on tomcat mailing list 
will create such blunders. I sincerely apologize for this as it was my first 
time on tom cat mailing list and it wont be repeated again. It was just me 
being proactive and completing my work on time and as fast as possible without 
considering the consequences(which i now got and again apologize for)

- -chris

-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7pCFgACgkQHPApP6U8
pFhLGA/+OCBFDtwXqg25GkHzJIVCCDz0PUmo+WwshsHXmg+6njQ6oyk0xfbqUQNh
2x4IQEsqi0wvTHXRBhWtK1RQfu1emcPdLADb7Fx58AAGzyc1aNSn/LPT3+XkVRJ1
D82SQVMFeoOtOxLTSRfWlHEvjthuV7g5nobKW5yDOiv0TR+CBqarAzSewvRis5DZ
9HtAzS3jZnZVC6cCdyScRYjc4vMYWhfVHzCaAvsSoMwR/+644xeN/6rUpl6eY8L/
gxBW+w1Vn7X91gLyXML1sHQhwaupCvw3jnaV5B/CkPGTUKufKV6x3Xpycg/OmNeI
7w9m5ukzFDqtwIfbep7ngHZyiWXCngkCH50bFc7q/O/7nlbrKNx6cBS6ifh9b7dX
go1juA3dLqekY98eZxKh8nz4U7hI6Snw0KQJruLiVin3E8F8LqUegvq5QJelsQql
IoZZaj44BaPvCHIzdUxLhMKj0YJEOH5TxG7/NyyCI98RLrz0hk+JbF1+7YREIN0s
NQk2701kfmrPy2XeywvNS8psXQEsh0QtL7WpFBBnw2LZefKlqX4OcMC3hAl1o2dS
RkakYu0/J7UCvvUg0wTG3kK/NDseOBi6sMLSXatgSXIa8nfhjxygxH/fBrrAJt/D
CSlHgXDLfJIsfz8sd+/htW2ACCmd6VpdYfcFc5p0fHpkz+tIE6c=
=jJNV
-END PGP SIGNATURE-

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



Sent from Outlook Mobile
This email and the information contained herein is proprietary and confidential 
and subject to the Amdocs Email Terms of Service, which you may review at 
https://www.amdocs.com/about/email-terms-of-service 

Re: [OT] [tomcat-users] Issue found during migration of Tomcat version 6.0.35 to 8.5.5

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

On 6/15/20 10:02, Jason Pyeron wrote:
> A quick brief on etiquette.
>
> 1.   Please do not harvest emails and send linked in requests

OMG +1 many many times to this.

If I haven't met you in person, don't send me a LinkedIn request.

> 2.   Do not mark questions as urgent and do provide sufficient
> details to reproduce the problem

I didn't see anything "urgent" about the initial post.

- -chris

-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7pCFgACgkQHPApP6U8
pFhLGA/+OCBFDtwXqg25GkHzJIVCCDz0PUmo+WwshsHXmg+6njQ6oyk0xfbqUQNh
2x4IQEsqi0wvTHXRBhWtK1RQfu1emcPdLADb7Fx58AAGzyc1aNSn/LPT3+XkVRJ1
D82SQVMFeoOtOxLTSRfWlHEvjthuV7g5nobKW5yDOiv0TR+CBqarAzSewvRis5DZ
9HtAzS3jZnZVC6cCdyScRYjc4vMYWhfVHzCaAvsSoMwR/+644xeN/6rUpl6eY8L/
gxBW+w1Vn7X91gLyXML1sHQhwaupCvw3jnaV5B/CkPGTUKufKV6x3Xpycg/OmNeI
7w9m5ukzFDqtwIfbep7ngHZyiWXCngkCH50bFc7q/O/7nlbrKNx6cBS6ifh9b7dX
go1juA3dLqekY98eZxKh8nz4U7hI6Snw0KQJruLiVin3E8F8LqUegvq5QJelsQql
IoZZaj44BaPvCHIzdUxLhMKj0YJEOH5TxG7/NyyCI98RLrz0hk+JbF1+7YREIN0s
NQk2701kfmrPy2XeywvNS8psXQEsh0QtL7WpFBBnw2LZefKlqX4OcMC3hAl1o2dS
RkakYu0/J7UCvvUg0wTG3kK/NDseOBi6sMLSXatgSXIa8nfhjxygxH/fBrrAJt/D
CSlHgXDLfJIsfz8sd+/htW2ACCmd6VpdYfcFc5p0fHpkz+tIE6c=
=jJNV
-END PGP SIGNATURE-

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

Re: Warning "AJP13 protocol: Reuse is set to false" written logs every second of every day. Please help.

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Alfred,

On 6/15/20 09:45, Alfred Bakia wrote:
> Thanks, Chris. To respond to your remarks:
>
> 1) The warnings, "AJP13 protocol: Reuse is set to false", are
> being
logged by Tomcat (in the Tomcat AJP connector logs).

Weird. I can't find that string anywhere in code or other files in
Tomcat, but its right there in mod_jk:

./native/common/jk_ajp_common.c:jk_log(l, JK_LOG_WARNING,
"(%s) AJP13 protocol: Reuse is set to false",

Are you sure you are looking at the right log file?

> 2) As I mentioned earlier, the versions and settings of the
> servers (and their respective IIS web servers) are the same.
>
> In any case I have discovered "how" the warning occurs. It is
> indeed triggered by the REST API.
>
> The culprit is a REST request in the form:
>
> http://www.ourdomain.com/api/srv2/exercises/93/1431/26346/ping
>
> It is a POST request and "ping" is a custom REST method. It is
> just a ping, so the status code of the response is 204 ("No
> Content").

A 204 response should not cause any problem.

> I can confirm that every ping request results in the warning
> "AJP13 protocol: Reuse is set to false" being written to Tomcat's
> connector logs.
>
> Researching this on the web, I found the suggestion to add
> allowedRequestAttributesPattern=".*" to the AJP connector in
> server.xml.
>
> Is this a viable solution?

This has nothing to do with your REST API. This is a change made to
recent versions of Tomcat that may require you to allow certain
non-standard variables to be passed-over from your web server to
Tomcat via AJP.

If your "ping" REST API is requiring some information to be passed
from the web server to Tomcat and you are seeing errors on the Tomcat
side, then you may have to fiddle with the
allowedRequestAttributesPattern. Setting the value to ".*" is a
violation of sane security policy.

But I see no evidence that your "Reuse is set to false" error is
related (yet) to the allowedRequestAttributesPattern. If you see
errors in the Tomcat log, please post them and we'll see.

The allowedRequestAttributesPattern wasn't added to Tomcat until
9.0.31 so if you really are running 9.0.21, then adding
allowedRequestAttributesPattern will accomplish nothing.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7pB3wACgkQHPApP6U8
pFg97w//T8XVtWlic/x/nUJHZUXfDs99Ou8cKcSFFI/AbBldd5k8vSxCTKg40wON
3bUooWG5GWZhVRNHH2JH0eyiKqhLmDtAzdnSp7xAkAW2fAZ2Zlv0VLb0AzJCTqRg
e1Nd9R9Ii9mjcSU5+M2WrNSourUhOT0FVYaqpvlaN89XyetHSuVIUladDuwM8kFN
3ngAtkgmIYfxXcqIPXjoNZ+s8cr1MB0qk+KkiXyOCb8XgfmZUkBMRncgqMAgEff5
p6Z/1jGVv0+S7E0+HV1yqJpakiGjVswfIjbc2s89YnVL6bvyBqUnJl4HrmOHY0bV
d3O/NQ3+vZ/Kma4e84TI5QKQx0KvQj0oBH41fFl0WmPjraKjGMTTfMCy9BjvLwdf
hbTEbZaBRvn7Tr+iR5ksrvaJTxZD1ABMb7o0uksCsPQO8h3tl3s7L5O4g0P3+7kV
/SiqDD+WyqkhmJuX86Y3MtSeMUTsg9RiXOZLLGF59TOZFeso/2O+OWYU/uImXw2X
opWW38Vowhn8O9a94RbRA67EvJFiLdWwTDoLlnVP0ZxGkdOIow0EQWfnCDKaBXOd
l+BdTG7zPbU8I3bw00cXGytyCYENt9uIZJ/XVVkyC2EAFAbEArVjWR0ocZT4W6zQ
bCc5vbHFJnNvCRh8jeSl9ORSzBFzYPt0B1kvSMkNE0U7y7mU74c=
=8kiV
-END PGP SIGNATURE-

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

Re: Tomcat rfc6265 Cookie Dates

[Mark Thomas]

On 13/06/2020 19:20, S V Pavankumar wrote:
> Hi,
> 
> I am checking the RFC6265 as we wanted to switch to the RFC6265 Cookie 
> processor. One thing I have noticed is around, the way cookie expires date is 
> written to the response.
> 
> As per the RFC the date should follow RFC1123 date format 
> https://tools.ietf.org/html/rfc6265#section-4.1.1

The use of "SHOULD" in that requirement allows implementations to
deviate from the requirement with good reason.

Tomcat is using:
"EEE, dd-MMM- HH:mm:ss z"

The HTTP formats are:
"EEE, dd MMM  HH:mm:ss z"(preferred)
"EE, dd-MMM-yy HH:mm:ss zzz" (obsolete)
"EEE  d HH:mm:ss "   (obsolete)

If you look at the comments in the source code, you will see that the
date format Tomcat is using is the date format defined by the original
(Netscape, version 0) cookie specification.

The reason for this is the historically appalling record browsers have
for implementing the cookie specifications. The expires attribute is
only being added because Microsoft browsers didn't (still don't?)
understand the Max-Age attribute. I don't recall if the original
Netscape format was chosen because the Microsoft browsers required it or
if it was just the result of being cautious.

For some background see:

https://tomcat.markmail.org/thread/g6sipbofsjossacn

> Tomcat date is getting started with short wkday then following date2 
> (contains dashes) format instead of date1.  I see both the cookie processors 
> of tomcat are following the same pattern. Can tomcat keep the behavior 
> according to RFC in future updates ?

Changing anything related to cookies has historically broken stuff so I
am very reluctant to do so. Is this behaviour breaking something for
you? If so, what? I'd expect any RFC6265 compliant client to be able to
parse an Expires attribute generated by Tomcat.

Mark

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