Re: Fwd: SSL Configuration Help :

[Christopher Schultz]

Elavarasan,

On 10/6/23 06:32, Elavarasan Pugazhendi wrote:

Hi,

I have a pfx certificate and am trying to import it into a keystore before
configuring it within the tomcat but not able to add the pfx certificate. I
followed the below steps but wasn't able to add the certificate

Tomcat: 9.0.62
OS: RHEL 8

1. keytool -genkey -alias tomcat.net -keyalg RSA -keystore tomcat.jks
Entered the Q&A .
2. Using the pfx file. I create .crt and .key file using the below command
openssl pkcs12 -in crt.pfx -nocerts -out mykey.key
openssl pkcs12 -in crt.pfx -clcerts -nokeys -out mycert.crt
3. export certificate
openssl pkcs12 -export -in mykey.key -chain -CAfile crt.pfx -name
otomcat.net -out tomcat.jks


This last one won't work, at least not the way you expect. openssl can't 
create a JKS file, only PKCS12 / p12 / pfx. By using the openssl pkcs12 
-export command above, you will likely destroy your tomcat.jks file or 
just get a failure.


It's not entirely clear what you are trying to do. Are you trying to 
create a self-signed certificate, or are you trying to get your server 
certificate signed by a Certificate Authority?


If you just need a self-signed cert, then your first command should be 
sufficient -- just remember to set certificateAlias="tomcat.net" if you 
use that alias when creating your initial file. I would recommend using. 
a PKCS12 file when originally creating the keystore, just because JKS 
isn't supported by anything other than Java. All you need to do is make 
sure you have "-keystoretype PKCS12". With your version of Java, that 
may be the default already, but it doesn't hurt to be specific.


-chris

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

Re: Fwd: users Digest 17 Aug 2022 09:26:06 -0000 Issue 14393 - "BLANK" DIGEST MESSAGE ATTACHMENTS

[Terence M. Bandoian]

On 9/8/2022 9:45 AM, Berneburg, Cris J. - US wrote:

2. Also, some digest messages are blank for me, but other
folks' replies to them are not.  It's often original messages
from specific users.  Maybe we can compare what we see.
Not using multiple client apps, I don't know if the blankness
is due to client app misinterpretation or if the problem
originates on the server.  I have not been keeping track of
how long this has been happening, but it seems to be a
"recent" issue, at least for me.  FYI, I use MS Outlook on Exchange Server.

Well, that's ironic.  :-)  My own messages in digest are blank!

--
Cris Berneburg
CACI Senior Software Engineer




This electronic message contains information from CACI International Inc or 
subsidiary companies, which may be company sensitive, proprietary, privileged 
or otherwise protected from disclosure. The information is intended to be used 
solely by the recipient(s) named above. If you are not an intended recipient, 
be aware that any review, disclosure, copying, distribution or use of this 
transmission or its contents is prohibited. If you have received this 
transmission in error, please notify the sender immediately.

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




Hi, Cris-

That's funny!

I don't think we can do anything about base64-encoded messages for now. 
For some other content transfer encodings, inserting a blank line at the 
beginning of the content seems to help.


-Terence Bandoian


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

RE: Fwd: users Digest 17 Aug 2022 09:26:06 -0000 Issue 14393 - "BLANK" DIGEST MESSAGE ATTACHMENTS

[Berneburg, Cris J. - US]

Terence

> I created an issue for the blank digest messages:
> https://issues.apache.org/jira/browse/INFRA-23675
> which appears to be due a missing CRLF sequence following
> the header section. It's currently "WAITING FOR INFRA" so
> I don't think anyone has had a chance to look at it.

Thanks for investigating and reporting the issue.  :-)  Glad to know the cause 
has been identified.

--
Cris Berneburg
CACI Senior Software Engineer




This electronic message contains information from CACI International Inc or 
subsidiary companies, which may be company sensitive, proprietary, privileged 
or otherwise protected from disclosure. The information is intended to be used 
solely by the recipient(s) named above. If you are not an intended recipient, 
be aware that any review, disclosure, copying, distribution or use of this 
transmission or its contents is prohibited. If you have received this 
transmission in error, please notify the sender immediately.

Re: Fwd: users Digest 17 Aug 2022 09:26:06 -0000 Issue 14393 - "BLANK" DIGEST MESSAGE ATTACHMENTS

[Terence M. Bandoian]

On 9/8/2022 8:55 AM, Berneburg, Cris J. - US wrote:

Hi Terence

I have similar issues.


First, I was suddenly unable to send e-mail to the list using an
e-mail address that I have used on the list since at least 2005,
as mentioned above. I got around this by (re)subscribing to both
users and users-digest. This may be why you found my e-mail
address listed twice as a subscriber.
What isn't clear is whether a subscription to the list in the non-
digest form is now required to send messages to the list. (I was
previously subscribed to the digest only and had been able to
send messages to the list.) I should be able to test this without
too much trouble.

1. I stopped being able to reply to the digest after being subscribed for a few years.  Thanks for 
the idea about subbing to the "users" messaging service.  At Mark's suggestion, I opened 
a Jira ticket, which is still unresolved, "Subscriber Reply Posts to users@tomcat.apache.org 
Bounced".  https://issues.apache.org/jira/browse/INFRA-23619  I now see individual messages 
from myself since subscribing to that service (in addition to the digest).


Second, some attachments in the digest are still not displayed
in Thunderbird (shown as blank).I previously mistakenly reported
that some digest attachments were not displayed in gmail but that
looks to have been due to operator error as I'm now able to see
attachments in gmail including those shown as blank in Thunderbird.

2. Also, some digest messages are blank for me, but other folks' replies to them are not. 
 It's often original messages from specific users.  Maybe we can compare what we see.  
Not using multiple client apps, I don't know if the blankness is due to client app 
misinterpretation or if the problem originates on the server.  I have not been keeping 
track of how long this has been happening, but it seems to be a "recent" issue, 
at least for me.  FYI, I use MS Outlook on Exchange Server.

--
Cris Berneburg
CACI Senior Software Engineer




This electronic message contains information from CACI International Inc or 
subsidiary companies, which may be company sensitive, proprietary, privileged 
or otherwise protected from disclosure. The information is intended to be used 
solely by the recipient(s) named above. If you are not an intended recipient, 
be aware that any review, disclosure, copying, distribution or use of this 
transmission or its contents is prohibited. If you have received this 
transmission in error, please notify the sender immediately.

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




Hi, Cris-

Thanks for creating the JIRA issue about not being able to send messages 
to the list. From the comments on the issue, it appears they've 
identified a problem.


I created an issue for the blank digest messages:

https://issues.apache.org/jira/browse/INFRA-23675

which appears to be due a missing CRLF sequence following the header 
section. It's currently "WAITING FOR INFRA" so I don't think anyone has 
had a chance to look at it.


-Terence Bandoian


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

RE: Fwd: users Digest 17 Aug 2022 09:26:06 -0000 Issue 14393 - "BLANK" DIGEST MESSAGE ATTACHMENTS

[Berneburg, Cris J. - US]

> 2. Also, some digest messages are blank for me, but other
> folks' replies to them are not.  It's often original messages
> from specific users.  Maybe we can compare what we see.
> Not using multiple client apps, I don't know if the blankness
> is due to client app misinterpretation or if the problem
> originates on the server.  I have not been keeping track of
> how long this has been happening, but it seems to be a
> "recent" issue, at least for me.  FYI, I use MS Outlook on Exchange Server.

Well, that's ironic.  :-)  My own messages in digest are blank!

--
Cris Berneburg
CACI Senior Software Engineer




This electronic message contains information from CACI International Inc or 
subsidiary companies, which may be company sensitive, proprietary, privileged 
or otherwise protected from disclosure. The information is intended to be used 
solely by the recipient(s) named above. If you are not an intended recipient, 
be aware that any review, disclosure, copying, distribution or use of this 
transmission or its contents is prohibited. If you have received this 
transmission in error, please notify the sender immediately.

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

RE: Fwd: users Digest 17 Aug 2022 09:26:06 -0000 Issue 14393 - "BLANK" DIGEST MESSAGE ATTACHMENTS

[Berneburg, Cris J. - US]

Hi Terence

I have similar issues.

> First, I was suddenly unable to send e-mail to the list using an
> e-mail address that I have used on the list since at least 2005,
> as mentioned above. I got around this by (re)subscribing to both
> users and users-digest. This may be why you found my e-mail
> address listed twice as a subscriber.

> What isn't clear is whether a subscription to the list in the non-
> digest form is now required to send messages to the list. (I was
> previously subscribed to the digest only and had been able to
> send messages to the list.) I should be able to test this without
> too much trouble.

1. I stopped being able to reply to the digest after being subscribed for a few 
years.  Thanks for the idea about subbing to the "users" messaging service.  At 
Mark's suggestion, I opened a Jira ticket, which is still unresolved, 
"Subscriber Reply Posts to users@tomcat.apache.org Bounced".  
https://issues.apache.org/jira/browse/INFRA-23619  I now see individual 
messages from myself since subscribing to that service (in addition to the 
digest).

> Second, some attachments in the digest are still not displayed
> in Thunderbird (shown as blank).I previously mistakenly reported
> that some digest attachments were not displayed in gmail but that
> looks to have been due to operator error as I'm now able to see
> attachments in gmail including those shown as blank in Thunderbird.

2. Also, some digest messages are blank for me, but other folks' replies to 
them are not.  It's often original messages from specific users.  Maybe we can 
compare what we see.  Not using multiple client apps, I don't know if the 
blankness is due to client app misinterpretation or if the problem originates 
on the server.  I have not been keeping track of how long this has been 
happening, but it seems to be a "recent" issue, at least for me.  FYI, I use MS 
Outlook on Exchange Server.

--
Cris Berneburg
CACI Senior Software Engineer




This electronic message contains information from CACI International Inc or 
subsidiary companies, which may be company sensitive, proprietary, privileged 
or otherwise protected from disclosure. The information is intended to be used 
solely by the recipient(s) named above. If you are not an intended recipient, 
be aware that any review, disclosure, copying, distribution or use of this 
transmission or its contents is prohibited. If you have received this 
transmission in error, please notify the sender immediately.

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

Re: Fwd: users Digest 17 Aug 2022 09:26:06 -0000 Issue 14393 - "BLANK" DIGEST MESSAGE ATTACHMENTS

[Terence M. Bandoian]

On 9/7/2022 1:35 AM, Mark Thomas wrote:

On 07/09/2022 04:22, Terence M. Bandoian wrote:

It looks like there's something going on with the CRLF sequence that 
should separate the header section from the body in digest 
attachments. However, it's difficult to tell where it's happening.


 From RFC 5322:

    A message consists of header fields (collectively called "the header
    section of the message") followed, optionally, by a body. The header
    section is a sequence of lines of characters with special syntax as
    defined in this specification.  The body is simply a sequence of
    characters that follows the header section and is separated from the
    header section by an empty line (i.e., a line with nothing preceding
    the CRLF).

In Thunderbird, in every attachment that is displayed as blank or is 
missing a leading portion of the message, there is no empty line 
between the header section and the body in the message source.


In gmail, those attachments are displayed, mostly, but when I 
download the source, there is no empty line separating the header 
section from the body. I say mostly because, in some cases, gmail 
does not display a leading portion of the message, but starts after 
the first blank line.


This suggests that the digest is not including empty lines between 
the header section and body of attachments. I found a couple of 
digests from 2020 and, in all attachments, an empty line was included 
between the header section and body.


Has the digest code changed recently?


Thanks for looking into this.

ezmlm (the software that runs the mailing lists) was updated around 
the time you first reported these problems.


Please raise the issue of the missing line with the ASF infrastructure 
team as they manage ezmlm for all ASF projects.


Thanks again,

Mark

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



Done.

-Terence


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

Re: Fwd: users Digest 17 Aug 2022 09:26:06 -0000 Issue 14393 - "BLANK" DIGEST MESSAGE ATTACHMENTS

[Mark Thomas]

On 07/09/2022 04:22, Terence M. Bandoian wrote:

It looks like there's something going on with the CRLF sequence that 
should separate the header section from the body in digest attachments. 
However, it's difficult to tell where it's happening.


 From RFC 5322:

    A message consists of header fields (collectively called "the header
    section of the message") followed, optionally, by a body.  The header
    section is a sequence of lines of characters with special syntax as
    defined in this specification.  The body is simply a sequence of
    characters that follows the header section and is separated from the
    header section by an empty line (i.e., a line with nothing preceding
    the CRLF).

In Thunderbird, in every attachment that is displayed as blank or is 
missing a leading portion of the message, there is no empty line between 
the header section and the body in the message source.


In gmail, those attachments are displayed, mostly, but when I download 
the source, there is no empty line separating the header section from 
the body. I say mostly because, in some cases, gmail does not display a 
leading portion of the message, but starts after the first blank line.


This suggests that the digest is not including empty lines between the 
header section and body of attachments. I found a couple of digests from 
2020 and, in all attachments, an empty line was included between the 
header section and body.


Has the digest code changed recently?


Thanks for looking into this.

ezmlm (the software that runs the mailing lists) was updated around the 
time you first reported these problems.


Please raise the issue of the missing line with the ASF infrastructure 
team as they manage ezmlm for all ASF projects.


Thanks again,

Mark

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

Re: Fwd: users Digest 17 Aug 2022 09:26:06 -0000 Issue 14393 - "BLANK" DIGEST MESSAGE ATTACHMENTS

[Terence M. Bandoian]

On 9/6/2022 6:00 PM, Terence M. Bandoian wrote:

On 8/23/2022 1:47 AM, Mark Thomas wrote:

On 23/08/2022 02:45, Terence M. Bandoian wrote:
Recently, message attachments that appear blank in my e-mail client 
have been included in the Tomcat users mailing list digest.  Some 
users' messages are normally not blank (e.g. Tomcat committers and 
others). Messages from other users are.  Replies to "blank" messages 
by users whose messages are not blanked include the original 
message.  My e-mail client has not changed.


This message is a forward of a digest in which all of the message 
attachments appear blank in my e-mail client.  They also appear 
blank in GMail.  However, the attachments do include data which may 
be accessed by viewing the message source.


Has anyone else experienced this?


I haven't. I use Thunderbird as an email client.


Is this something that can be fixed by anyone on this list?


I don't think it is purely a list level configuration issue. I 
suspect a combination sender's email client, list server behaviour 
(possibly digest related) and receiver's email client.


What I would recommend is sending emails in plain text ("proper" 
plain text - not a plain text part in a multi-part message).



Should it be reported on the Tomcat bugzilla or somewhere else?


If you can show that the ASF list software is violating a relevant 
RFC then you can raise an issue with the ASF infrastructure team via 
the ASF Jira instance. That said, my experience is that it is email 
clients that tend to play fast and loose with the RFCs.


In addition, I have been unable to send e-mail to 
users@tomcat.apache.org from tere...@tmbsw.com which I have used on 
this list since at least 2005.  I receive the following error reply:


I've checked the list subscription and you appear to be listed twice. 
I'm not sure if that is causing issues so I have removed one of the 
subscriptions.


Mark





Hi. This is the qmail-send program at apache.org.
I'm afraid I wasn't able to deliver your message to the following 
addresses.

This is a permanent error; I've given up. Sorry it didn't work out.

:
Must be sent from an @apache.org address or a subscriber address or 
an address in LDAP.


Has something changed?  Do I need to reconfigure my mail server?  If 
so, in what way?


-Terence Bandoian




Hi, Mark-

Thanks for looking into this. It appears there were/are two problems.

First, I was suddenly unable to send e-mail to the list using an 
e-mail address that I have used on the list since at least 2005, as 
mentioned above. I got around this by (re)subscribing to both users 
and users-digest. This may be why you found my e-mail address listed 
twice as a subscriber.


What isn't clear is whether a subscription to the list in the 
non-digest form is now required to send messages to the list. (I was 
previously subscribed to the digest only and had been able to send 
messages to the list.) I should be able to test this without too much 
trouble.


Second, some attachments in the digest are still not displayed in 
Thunderbird (shown as blank).I previously mistakenly reported that 
some digest attachments were not displayed in gmail but that looks to 
have been due to operator error as I'm now able to see attachments in 
gmail including those shown as blank in Thunderbird.


I'll keep looking at this and report back to the list if I learn 
anything useful.


Thanks again for your time and effort.

-Terence Bandoian



 Forwarded Message 
Subject: users Digest 17 Aug 2022 09:26:06 - Issue 14393
Date: 17 Aug 2022 09:26:06 -
From: users-digest-h...@tomcat.apache.org
Reply-To: Tomcat Users List 
To: users@tomcat.apache.org




users Digest 17 Aug 2022 09:26:06 - Issue 14393

Topics (messages 275525 through 275527)

Re: Getting error on Tomcat Start
275525 by: Mohan T
275526 by: Thomas Meyer
275527 by: Mohan T

Administrivia:

-
To post to the list, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-digest-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-digest-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






It looks like there's something going on with the CRLF sequence that 
should separate the header section from the body in digest attachments. 
However, it's difficult to tell where it's happening.


From RFC 5322:

   A message consists of header fields (collectively called "the header
   section of the message") followed, optionally, by a body.  The header

Re: Fwd: users Digest 17 Aug 2022 09:26:06 -0000 Issue 14393 - "BLANK" DIGEST MESSAGE ATTACHMENTS

[Terence M. Bandoian]

On 8/23/2022 1:47 AM, Mark Thomas wrote:

On 23/08/2022 02:45, Terence M. Bandoian wrote:
Recently, message attachments that appear blank in my e-mail client 
have been included in the Tomcat users mailing list digest.  Some 
users' messages are normally not blank (e.g. Tomcat committers and 
others). Messages from other users are.  Replies to "blank" messages 
by users whose messages are not blanked include the original 
message.  My e-mail client has not changed.


This message is a forward of a digest in which all of the message 
attachments appear blank in my e-mail client.  They also appear blank 
in GMail.  However, the attachments do include data which may be 
accessed by viewing the message source.


Has anyone else experienced this?


I haven't. I use Thunderbird as an email client.


Is this something that can be fixed by anyone on this list?


I don't think it is purely a list level configuration issue. I suspect 
a combination sender's email client, list server behaviour (possibly 
digest related) and receiver's email client.


What I would recommend is sending emails in plain text ("proper" plain 
text - not a plain text part in a multi-part message).



Should it be reported on the Tomcat bugzilla or somewhere else?


If you can show that the ASF list software is violating a relevant RFC 
then you can raise an issue with the ASF infrastructure team via the 
ASF Jira instance. That said, my experience is that it is email 
clients that tend to play fast and loose with the RFCs.


In addition, I have been unable to send e-mail to 
users@tomcat.apache.org from tere...@tmbsw.com which I have used on 
this list since at least 2005.  I receive the following error reply:


I've checked the list subscription and you appear to be listed twice. 
I'm not sure if that is causing issues so I have removed one of the 
subscriptions.


Mark





Hi. This is the qmail-send program at apache.org.
I'm afraid I wasn't able to deliver your message to the following 
addresses.

This is a permanent error; I've given up. Sorry it didn't work out.

:
Must be sent from an @apache.org address or a subscriber address or 
an address in LDAP.


Has something changed?  Do I need to reconfigure my mail server?  If 
so, in what way?


-Terence Bandoian




Hi, Mark-

Thanks for looking into this. It appears there were/are two problems.

First, I was suddenly unable to send e-mail to the list using an e-mail 
address that I have used on the list since at least 2005, as mentioned 
above. I got around this by (re)subscribing to both users and 
users-digest. This may be why you found my e-mail address listed twice 
as a subscriber.


What isn't clear is whether a subscription to the list in the non-digest 
form is now required to send messages to the list. (I was previously 
subscribed to the digest only and had been able to send messages to the 
list.) I should be able to test this without too much trouble.


Second, some attachments in the digest are still not displayed in 
Thunderbird (shown as blank).I previously mistakenly reported that some 
digest attachments were not displayed in gmail but that looks to have 
been due to operator error as I'm now able to see attachments in gmail 
including those shown as blank in Thunderbird.


I'll keep looking at this and report back to the list if I learn 
anything useful.


Thanks again for your time and effort.

-Terence Bandoian



 Forwarded Message 
Subject: users Digest 17 Aug 2022 09:26:06 - Issue 14393
Date: 17 Aug 2022 09:26:06 -
From: users-digest-h...@tomcat.apache.org
Reply-To: Tomcat Users List 
To: users@tomcat.apache.org




users Digest 17 Aug 2022 09:26:06 - Issue 14393

Topics (messages 275525 through 275527)

Re: Getting error on Tomcat Start
275525 by: Mohan T
275526 by: Thomas Meyer
275527 by: Mohan T

Administrivia:

-
To post to the list, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-digest-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-digest-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: Fwd: users Digest 17 Aug 2022 09:26:06 -0000 Issue 14393 - "BLANK" DIGEST MESSAGE ATTACHMENTS

[Mark Thomas]

On 23/08/2022 02:45, Terence M. Bandoian wrote:
Recently, message attachments that appear blank in my e-mail client have 
been included in the Tomcat users mailing list digest.  Some users' 
messages are normally not blank (e.g. Tomcat committers and others). 
Messages from other users are.  Replies to "blank" messages by users 
whose messages are not blanked include the original message.  My e-mail 
client has not changed.


This message is a forward of a digest in which all of the message 
attachments appear blank in my e-mail client.  They also appear blank in 
GMail.  However, the attachments do include data which may be accessed 
by viewing the message source.


Has anyone else experienced this?


I haven't. I use Thunderbird as an email client.


Is this something that can be fixed by anyone on this list?


I don't think it is purely a list level configuration issue. I suspect a 
combination sender's email client, list server behaviour (possibly 
digest related) and receiver's email client.


What I would recommend is sending emails in plain text ("proper" plain 
text - not a plain text part in a multi-part message).



Should it be reported on the Tomcat bugzilla or somewhere else?


If you can show that the ASF list software is violating a relevant RFC 
then you can raise an issue with the ASF infrastructure team via the ASF 
Jira instance. That said, my experience is that it is email clients that 
tend to play fast and loose with the RFCs.


In addition, I have been unable to send e-mail to 
users@tomcat.apache.org from tere...@tmbsw.com which I have used on this 
list since at least 2005.  I receive the following error reply:


I've checked the list subscription and you appear to be listed twice. 
I'm not sure if that is causing issues so I have removed one of the 
subscriptions.


Mark





Hi. This is the qmail-send program at apache.org.
I'm afraid I wasn't able to deliver your message to the following 
addresses.

This is a permanent error; I've given up. Sorry it didn't work out.

:
Must be sent from an @apache.org address or a subscriber address or an 
address in LDAP.


Has something changed?  Do I need to reconfigure my mail server?  If so, 
in what way?


-Terence Bandoian


 Forwarded Message 
Subject: users Digest 17 Aug 2022 09:26:06 - Issue 14393
Date: 17 Aug 2022 09:26:06 -
From: users-digest-h...@tomcat.apache.org
Reply-To: Tomcat Users List 
To: users@tomcat.apache.org




users Digest 17 Aug 2022 09:26:06 - Issue 14393

Topics (messages 275525 through 275527)

Re: Getting error on Tomcat Start
275525 by: Mohan T
275526 by: Thomas Meyer
275527 by: Mohan T

Administrivia:

-
To post to the list, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-digest-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-digest-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: Fwd: tomcat 9.50 - rewrite rule question

[Christopher Schultz]

Rupali,

On 3/25/22 11:28, rupali singh wrote:

hi chris,

Apologies for typo mistakes.

business user are using url :   https://xyz.ae/apex/f?p=1001
   to login into apex application and login
is working fine.

xyz.ae is published in our F5 which is pointing to tomcat server on port
8080  hence im not worried about xyz.ae

for making is simple for user we want to rename f?p=1001
   to myapp
so business user will use https://xyz.ae/apex/myapp


So our requirement is  :   in url we want to replace f?p=1001
 to myapp


tried below but not working

RewriteCond %{QUERY_STRING} p=1001
RewriteRule ^/f$ /apex/myapp


It looks like you are doing this backward: your rewrite rule will take a 
URL coming from a user (at the time they request it!) which looks like this:


https://xyz.ae/apex/f?p=1001

and re-write the URL to:

/apex/myapp

You want to do the opposite: the user supplies the URL /apex/myapp and 
you internally convert it to /apex/f?p=1001


Right?

You want users to use the "friendly" URLs, not the internal system.


rewrite.config location :
/opt/tomcat/apache-tomcat-9.0.54/instance/webapps/ROOT/WEB-INF/rewrite.config


This is the major problem: you have put your rewrite rules into the ROOT 
web application (context path=/), but your request is being sent to the 
web application deployed into the /apex context path.


You need to:

1. Move your file to .../instance/webapps/apex/WEB-INF/rewrite.config
2. Remove the "/apex" from the beginning of all your URLs in rewrite.config


curl output:
curl -D- 'localhost:8080/apex/f?p=10001'
HTTP/1.1 302
X-Content-Type-Options: nosniff
X-Xss-Protection: 1; mode=block
Referrer-Policy: strict-origin-when-cross-origin
Location: https://localhost/apex/workspace/r/abcrelease10001123100/home
Transfer-Encoding: chunked
Date: Fri, 25 Mar 2022 15:18:16 GMT


Hm. So you really *do* want to re-write non-friendly URLs into 
friendly ones. I'm very confused.


So you are expecting a 302 response from Tomcat but pointing to 
/apex/myapp ?


What component of your system is returning the 302 above?

-chris


On Fri, 25 Mar 2022 at 16:52, Christopher Schultz <
ch...@christopherschultz.net> wrote:


Rupali,

This has gone around in circles for a while with no progress. Can you
please:

1. Show examples of what you would like. Specific examples, like:

"I expect that when requesting http://xyz.ae/apex/?f=1001"; I get a 302
redirect to http://xyz.ae/apex/myapp";

That's what you are asking for, but I suspect that what you really want
is the reverse: users who request /myapp actually get "?f=1001".

This is further complicated by the fact that all your URLs show as
ayx.ae in text, but then have  added to the end for some
reason. Which is it?

Do you want an HTTP redirect? If so, what kind? Or do you want your
server to proxy from one URL to the other, so the client doesn't know
it's happening?

2. Which component should be responsible for all of this? You have
several networking components to choose from:

a. F5 load balancer
b. Oracle Apex
c. Apache Tomcat

Why have you decided to re-write your application's URLs at the Tomcat
level and not somewhere further up the chain?

3. Show exactly what you currently have in your rewrite config file, and
exactly where that rewrite configuration file is on the disk.

Going back to your original post, lots of things are confusing:

i. The URLs are inconsistent (.ae va .com, apex vs aorx)

ii. You appear to be asking to redirect from non-friendly URLs to
friendly URLs which doesn't make any sense. Perhaps this is a
terminology issue. You want clients to use the friendly URLs
(/apex/myapp) and then get what they would have received had they called
/f?p=1001 right?

iii. You are redirecting /myapp to /myapp in your example, which
accomplishes nothing. You also have the same rule twice.

This should be as simple as:

RewriteRule "^/f?p=1001" "/myapp"

... but it's not, because RewriteRule only looks at the path and not the
query string, so you need a separate condition. I'll repeat what Felix
(almost) posted a few days ago, which should be correct:

RewriteCond %{QUERY_STRING} p=1001
RewriteRule ^/f$ /apex/myapp

I don't think you even want the [R] flag because if you do that, the
client will see the URL change to the unfriendly URL, and the point is
to hide that from them, right?

The last thing to do is to make sure the file is *in the right place*.
No amount of configuration in C:\Windows\rewrite.config is going to have
any effect unless you have a very strange configuration.

-chris

On 3/24/22 14:23, rupali singh wrote:

hi,

yes context name is apex.

   https://xyz.ae/apex/f?p=1001    to
https://xyz.ae/apex/myapp 

we dont want to change xyz.ae that will name remain as it is , we want

to

change f?p=1001  to myapp



On Wed, 23

Re: Fwd: tomcat 9.50 - rewrite rule question

[rupali singh]

hi chris,

Apologies for typo mistakes.

business user are using url :   https://xyz.ae/apex/f?p=1001
   to login into apex application and login
is working fine.

xyz.ae is published in our F5 which is pointing to tomcat server on port
8080  hence im not worried about xyz.ae

for making is simple for user we want to rename f?p=1001
   to myapp
so business user will use https://xyz.ae/apex/myapp


So our requirement is  :   in url we want to replace f?p=1001
 to myapp


tried below but not working

RewriteCond %{QUERY_STRING} p=1001
RewriteRule ^/f$ /apex/myapp

rewrite.config location :
/opt/tomcat/apache-tomcat-9.0.54/instance/webapps/ROOT/WEB-INF/rewrite.config


Thanks Peter for suggestion but configure friendly URLs is not our
requirement.


We have achieved  our requirement  where apex is deployed on oracle
weblogic with Oracle HTTP server.
Now same want to achieve with apex-tomcat


curl output:
curl -D- 'localhost:8080/apex/f?p=10001'
HTTP/1.1 302
X-Content-Type-Options: nosniff
X-Xss-Protection: 1; mode=block
Referrer-Policy: strict-origin-when-cross-origin
Location: https://localhost/apex/workspace/r/abcrelease10001123100/home
Transfer-Encoding: chunked
Date: Fri, 25 Mar 2022 15:18:16 GMT

On Fri, 25 Mar 2022 at 16:52, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Rupali,
>
> This has gone around in circles for a while with no progress. Can you
> please:
>
> 1. Show examples of what you would like. Specific examples, like:
>
> "I expect that when requesting http://xyz.ae/apex/?f=1001"; I get a 302
> redirect to http://xyz.ae/apex/myapp";
>
> That's what you are asking for, but I suspect that what you really want
> is the reverse: users who request /myapp actually get "?f=1001".
>
> This is further complicated by the fact that all your URLs show as
> ayx.ae in text, but then have  added to the end for some
> reason. Which is it?
>
> Do you want an HTTP redirect? If so, what kind? Or do you want your
> server to proxy from one URL to the other, so the client doesn't know
> it's happening?
>
> 2. Which component should be responsible for all of this? You have
> several networking components to choose from:
>
> a. F5 load balancer
> b. Oracle Apex
> c. Apache Tomcat
>
> Why have you decided to re-write your application's URLs at the Tomcat
> level and not somewhere further up the chain?
>
> 3. Show exactly what you currently have in your rewrite config file, and
> exactly where that rewrite configuration file is on the disk.
>
> Going back to your original post, lots of things are confusing:
>
> i. The URLs are inconsistent (.ae va .com, apex vs aorx)
>
> ii. You appear to be asking to redirect from non-friendly URLs to
> friendly URLs which doesn't make any sense. Perhaps this is a
> terminology issue. You want clients to use the friendly URLs
> (/apex/myapp) and then get what they would have received had they called
> /f?p=1001 right?
>
> iii. You are redirecting /myapp to /myapp in your example, which
> accomplishes nothing. You also have the same rule twice.
>
> This should be as simple as:
>
> RewriteRule "^/f?p=1001" "/myapp"
>
> ... but it's not, because RewriteRule only looks at the path and not the
> query string, so you need a separate condition. I'll repeat what Felix
> (almost) posted a few days ago, which should be correct:
>
> RewriteCond %{QUERY_STRING} p=1001
> RewriteRule ^/f$ /apex/myapp
>
> I don't think you even want the [R] flag because if you do that, the
> client will see the URL change to the unfriendly URL, and the point is
> to hide that from them, right?
>
> The last thing to do is to make sure the file is *in the right place*.
> No amount of configuration in C:\Windows\rewrite.config is going to have
> any effect unless you have a very strange configuration.
>
> -chris
>
> On 3/24/22 14:23, rupali singh wrote:
> > hi,
> >
> > yes context name is apex.
> >
> >   https://xyz.ae/apex/f?p=1001    to
> > https://xyz.ae/apex/myapp 
> >
> > we dont want to change xyz.ae that will name remain as it is , we want
> to
> > change f?p=1001  to myapp
> >
> >
> >
> > On Wed, 23 Mar 2022 at 19:23, Felix Schumacher <
> > felix.schumac...@internetallee.de> wrote:
> >
> >>
> >>
> >> Am 23. März 2022 12:14:25 MEZ schrieb rupali singh <
> >> rupali.r.si...@gmail.com>:
> >>> Hi Chris,
> >>>
> >>> I already tried with fully qualified name but its not working
> >>
> >> Can you be more specific, what you tried?
> >>
> >> Is Chris right and your context name is apex?
> >>
> >> Felix
> >>>
> >>> On Tue, Mar 22, 2022, 7:15 PM Christopher Schultz <
> >>> ch...@christopherschultz.net> wrote:
> >>>
>  All,
> 
>  On 3/21/22 10:19, Felix Schumacher wrote:
> >
> > Am 21.03.22 um 06:39 schrieb rupali singh:
> >> Hi Felix,
> >>
> >> location of context.

Re: Fwd: tomcat 9.50 - rewrite rule question

[Christopher Schultz]

Rupali,

This has gone around in circles for a while with no progress. Can you 
please:


1. Show examples of what you would like. Specific examples, like:

"I expect that when requesting http://xyz.ae/apex/?f=1001"; I get a 302 
redirect to http://xyz.ae/apex/myapp";


That's what you are asking for, but I suspect that what you really want 
is the reverse: users who request /myapp actually get "?f=1001".


This is further complicated by the fact that all your URLs show as 
ayx.ae in text, but then have  added to the end for some 
reason. Which is it?


Do you want an HTTP redirect? If so, what kind? Or do you want your 
server to proxy from one URL to the other, so the client doesn't know 
it's happening?


2. Which component should be responsible for all of this? You have 
several networking components to choose from:


a. F5 load balancer
b. Oracle Apex
c. Apache Tomcat

Why have you decided to re-write your application's URLs at the Tomcat 
level and not somewhere further up the chain?


3. Show exactly what you currently have in your rewrite config file, and 
exactly where that rewrite configuration file is on the disk.


Going back to your original post, lots of things are confusing:

i. The URLs are inconsistent (.ae va .com, apex vs aorx)

ii. You appear to be asking to redirect from non-friendly URLs to 
friendly URLs which doesn't make any sense. Perhaps this is a 
terminology issue. You want clients to use the friendly URLs 
(/apex/myapp) and then get what they would have received had they called 
/f?p=1001 right?


iii. You are redirecting /myapp to /myapp in your example, which 
accomplishes nothing. You also have the same rule twice.


This should be as simple as:

RewriteRule "^/f?p=1001" "/myapp"

... but it's not, because RewriteRule only looks at the path and not the 
query string, so you need a separate condition. I'll repeat what Felix 
(almost) posted a few days ago, which should be correct:


RewriteCond %{QUERY_STRING} p=1001
RewriteRule ^/f$ /apex/myapp

I don't think you even want the [R] flag because if you do that, the 
client will see the URL change to the unfriendly URL, and the point is 
to hide that from them, right?


The last thing to do is to make sure the file is *in the right place*. 
No amount of configuration in C:\Windows\rewrite.config is going to have 
any effect unless you have a very strange configuration.


-chris

On 3/24/22 14:23, rupali singh wrote:

hi,

yes context name is apex.

  https://xyz.ae/apex/f?p=1001    to
https://xyz.ae/apex/myapp 

we dont want to change xyz.ae that will name remain as it is , we want to
change f?p=1001  to myapp



On Wed, 23 Mar 2022 at 19:23, Felix Schumacher <
felix.schumac...@internetallee.de> wrote:




Am 23. März 2022 12:14:25 MEZ schrieb rupali singh <
rupali.r.si...@gmail.com>:

Hi Chris,

I already tried with fully qualified name but its not working


Can you be more specific, what you tried?

Is Chris right and your context name is apex?

Felix


On Tue, Mar 22, 2022, 7:15 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


All,

On 3/21/22 10:19, Felix Schumacher wrote:


Am 21.03.22 um 06:39 schrieb rupali singh:

Hi Felix,

location of context.xml file is

   cat context.xml| grep RewriteValve
  
className="org.apache.catalina.valves.rewrite.RewriteValve"

/>

   pwd
/opt/tomcat/apache-tomcat-9.0.54/instance/conf

That context.xml is thought to be a default template for all installed
webapps. It will work, but remember, that every installed webapp will
get its own copy of a rewrite valve.


+1

This is probably the problem.


more




/opt/tomcat/apache-tomcat-9.0.54/instance/webapps/ROOT/WEB-INF/rewrite.config

RewriteCond %{QUERY_STRING} p=10001
RewriteRule ^/apex/f$ /apex/myapp [R,L]



I think you want:

RewriteCond %{QUERY_STRING} p=10001
RewriteRule ^/f$ /myapp [R,L]

The prefix /apex is already a part of the context-path and should be
removed from the URL patterns being matched. If you want to redirect to
another web application, you need a fully-qualified redirect like this:

RewriteCond %{QUERY_STRING} p=10001
RewriteRule ^/f$ https://www.google.com/ [R,L]

-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






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

Re: Fwd: tomcat 9.50 - rewrite rule question

[Rob Sargent]

On 3/24/22 13:27, Peter Chiu wrote:

Application builder->Your application->Shared Components->Application
Definition Attributes->Properties->Friendly URLs



And that does what, exactly?


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

Re: Fwd: tomcat 9.50 - rewrite rule question

[Peter Chiu]

Application builder->Your application->Shared Components->Application
Definition Attributes->Properties->Friendly URLs

On Thu, Mar 24, 2022 at 3:25 PM rupali singh 
wrote:

> Hi,
>
> How we can enable friendly url in apex?
>
>
>
> On Fri, Mar 25, 2022, 12:48 AM Peter Chiu  wrote:
>
> > Have you consider doing the following
> > 1. custom URL/domain, and
> > 2. enable Friendly URLs in APEX
> >
> > On Thu, Mar 24, 2022 at 3:09 PM Felix Schumacher <
> > felix.schumac...@internetallee.de> wrote:
> >
> > >
> > > Am 24.03.22 um 19:23 schrieb rupali singh:
> > >
> > > hi,
> > >
> > > yes context name is apex.
> > >
> > > Good to know.
> > >
> > >  https://xyz.ae/apex/f?p=1001  <
> > https://xyz.com/apex/f?p=1001>   tohttps://xyz.ae/apex/myapp <
> > https://xyz.com/aorx/myapp> 
> > >
> > > we dont want to change xyz.ae that will name remain as it is , we want
> > to
> > > change f?p=1001  <
> > https://xyz.com/apex/f?p=1001> to myapp
> > >
> > > Sorry, I don't understand, what you meant by the above.
> > >
> > > I suspect, that you wanted to show, what the user enters into the
> browser
> > > and where the application listens. But it doesn't really makes sense to
> > me.
> > >
> > > Reading your first mail again, I think, that you have a loadbalancer
> that
> > > listens on xyz.ae and that proxies to xyz.com (you mentioned port
> 8080,
> > > which is left out in all your examples). Is that right?
> > >
> > > Apart from that, I wanted to know, what you tried on a technical level.
> > > Have you tried the curl command that I gave as an example?
> > >
> > > Felix
> > >
> > > On Wed, 23 Mar 2022 at 19:23, Felix Schumacher <
> > felix.schumac...@internetallee.de> wrote:
> > >
> > >
> > > Am 23. März 2022 12:14:25 MEZ schrieb rupali singh <
> > rupali.r.si...@gmail.com>:
> > >
> > > Hi Chris,
> > >
> > > I already tried with fully qualified name but its not working
> > >
> > > Can you be more specific, what you tried?
> > >
> > > Is Chris right and your context name is apex?
> > >
> > > Felix
> > >
> > > On Tue, Mar 22, 2022, 7:15 PM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> > >
> > >
> > > All,
> > >
> > > On 3/21/22 10:19, Felix Schumacher wrote:
> > >
> > > Am 21.03.22 um 06:39 schrieb rupali singh:
> > >
> > > Hi Felix,
> > >
> > > location of context.xml file is
> > >
> > >   cat context.xml| grep RewriteValve
> > >   > >
> > > className="org.apache.catalina.valves.rewrite.RewriteValve"
> > >
> > > />
> > >
> > >   pwd
> > > /opt/tomcat/apache-tomcat-9.0.54/instance/conf
> > >
> > > That context.xml is thought to be a default template for all installed
> > > webapps. It will work, but remember, that every installed webapp will
> > > get its own copy of a rewrite valve.
> > >
> > > +1
> > >
> > > This is probably the problem.
> > >
> > >
> > > more
> > >
> > >
> > >
> >
> /opt/tomcat/apache-tomcat-9.0.54/instance/webapps/ROOT/WEB-INF/rewrite.config
> > >
> > > RewriteCond %{QUERY_STRING} p=10001
> > > RewriteRule ^/apex/f$ /apex/myapp [R,L]
> > >
> > > I think you want:
> > >
> > > RewriteCond %{QUERY_STRING} p=10001
> > > RewriteRule ^/f$ /myapp [R,L]
> > >
> > > The prefix /apex is already a part of the context-path and should be
> > > removed from the URL patterns being matched. If you want to redirect to
> > > another web application, you need a fully-qualified redirect like this:
> > >
> > > RewriteCond %{QUERY_STRING} p=10001
> > > RewriteRule ^/f$ https://www.google.com/ [R,L]
> > >
> > > -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: Fwd: tomcat 9.50 - rewrite rule question

[rupali singh]

Hi,

How we can enable friendly url in apex?



On Fri, Mar 25, 2022, 12:48 AM Peter Chiu  wrote:

> Have you consider doing the following
> 1. custom URL/domain, and
> 2. enable Friendly URLs in APEX
>
> On Thu, Mar 24, 2022 at 3:09 PM Felix Schumacher <
> felix.schumac...@internetallee.de> wrote:
>
> >
> > Am 24.03.22 um 19:23 schrieb rupali singh:
> >
> > hi,
> >
> > yes context name is apex.
> >
> > Good to know.
> >
> >  https://xyz.ae/apex/f?p=1001  <
> https://xyz.com/apex/f?p=1001>   tohttps://xyz.ae/apex/myapp <
> https://xyz.com/aorx/myapp> 
> >
> > we dont want to change xyz.ae that will name remain as it is , we want
> to
> > change f?p=1001  <
> https://xyz.com/apex/f?p=1001> to myapp
> >
> > Sorry, I don't understand, what you meant by the above.
> >
> > I suspect, that you wanted to show, what the user enters into the browser
> > and where the application listens. But it doesn't really makes sense to
> me.
> >
> > Reading your first mail again, I think, that you have a loadbalancer that
> > listens on xyz.ae and that proxies to xyz.com (you mentioned port 8080,
> > which is left out in all your examples). Is that right?
> >
> > Apart from that, I wanted to know, what you tried on a technical level.
> > Have you tried the curl command that I gave as an example?
> >
> > Felix
> >
> > On Wed, 23 Mar 2022 at 19:23, Felix Schumacher <
> felix.schumac...@internetallee.de> wrote:
> >
> >
> > Am 23. März 2022 12:14:25 MEZ schrieb rupali singh <
> rupali.r.si...@gmail.com>:
> >
> > Hi Chris,
> >
> > I already tried with fully qualified name but its not working
> >
> > Can you be more specific, what you tried?
> >
> > Is Chris right and your context name is apex?
> >
> > Felix
> >
> > On Tue, Mar 22, 2022, 7:15 PM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
> >
> >
> > All,
> >
> > On 3/21/22 10:19, Felix Schumacher wrote:
> >
> > Am 21.03.22 um 06:39 schrieb rupali singh:
> >
> > Hi Felix,
> >
> > location of context.xml file is
> >
> >   cat context.xml| grep RewriteValve
> >   >
> > className="org.apache.catalina.valves.rewrite.RewriteValve"
> >
> > />
> >
> >   pwd
> > /opt/tomcat/apache-tomcat-9.0.54/instance/conf
> >
> > That context.xml is thought to be a default template for all installed
> > webapps. It will work, but remember, that every installed webapp will
> > get its own copy of a rewrite valve.
> >
> > +1
> >
> > This is probably the problem.
> >
> >
> > more
> >
> >
> >
> /opt/tomcat/apache-tomcat-9.0.54/instance/webapps/ROOT/WEB-INF/rewrite.config
> >
> > RewriteCond %{QUERY_STRING} p=10001
> > RewriteRule ^/apex/f$ /apex/myapp [R,L]
> >
> > I think you want:
> >
> > RewriteCond %{QUERY_STRING} p=10001
> > RewriteRule ^/f$ /myapp [R,L]
> >
> > The prefix /apex is already a part of the context-path and should be
> > removed from the URL patterns being matched. If you want to redirect to
> > another web application, you need a fully-qualified redirect like this:
> >
> > RewriteCond %{QUERY_STRING} p=10001
> > RewriteRule ^/f$ https://www.google.com/ [R,L]
> >
> > -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: Fwd: tomcat 9.50 - rewrite rule question

[Peter Chiu]

Have you consider doing the following
1. custom URL/domain, and
2. enable Friendly URLs in APEX

On Thu, Mar 24, 2022 at 3:09 PM Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

>
> Am 24.03.22 um 19:23 schrieb rupali singh:
>
> hi,
>
> yes context name is apex.
>
> Good to know.
>
>  https://xyz.ae/apex/f?p=1001  
>    tohttps://xyz.ae/apex/myapp 
>  
>
> we dont want to change xyz.ae that will name remain as it is , we want to
> change f?p=1001  
>  to myapp
>
> Sorry, I don't understand, what you meant by the above.
>
> I suspect, that you wanted to show, what the user enters into the browser
> and where the application listens. But it doesn't really makes sense to me.
>
> Reading your first mail again, I think, that you have a loadbalancer that
> listens on xyz.ae and that proxies to xyz.com (you mentioned port 8080,
> which is left out in all your examples). Is that right?
>
> Apart from that, I wanted to know, what you tried on a technical level.
> Have you tried the curl command that I gave as an example?
>
> Felix
>
> On Wed, 23 Mar 2022 at 19:23, Felix Schumacher 
>  wrote:
>
>
> Am 23. März 2022 12:14:25 MEZ schrieb rupali singh :
>
> Hi Chris,
>
> I already tried with fully qualified name but its not working
>
> Can you be more specific, what you tried?
>
> Is Chris right and your context name is apex?
>
> Felix
>
> On Tue, Mar 22, 2022, 7:15 PM Christopher Schultz 
>  wrote:
>
>
> All,
>
> On 3/21/22 10:19, Felix Schumacher wrote:
>
> Am 21.03.22 um 06:39 schrieb rupali singh:
>
> Hi Felix,
>
> location of context.xml file is
>
>   cat context.xml| grep RewriteValve
>  
> className="org.apache.catalina.valves.rewrite.RewriteValve"
>
> />
>
>   pwd
> /opt/tomcat/apache-tomcat-9.0.54/instance/conf
>
> That context.xml is thought to be a default template for all installed
> webapps. It will work, but remember, that every installed webapp will
> get its own copy of a rewrite valve.
>
> +1
>
> This is probably the problem.
>
>
> more
>
>
> /opt/tomcat/apache-tomcat-9.0.54/instance/webapps/ROOT/WEB-INF/rewrite.config
>
> RewriteCond %{QUERY_STRING} p=10001
> RewriteRule ^/apex/f$ /apex/myapp [R,L]
>
> I think you want:
>
> RewriteCond %{QUERY_STRING} p=10001
> RewriteRule ^/f$ /myapp [R,L]
>
> The prefix /apex is already a part of the context-path and should be
> removed from the URL patterns being matched. If you want to redirect to
> another web application, you need a fully-qualified redirect like this:
>
> RewriteCond %{QUERY_STRING} p=10001
> RewriteRule ^/f$ https://www.google.com/ [R,L]
>
> -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: Fwd: tomcat 9.50 - rewrite rule question

[Felix Schumacher]

Am 24.03.22 um 19:23 schrieb rupali singh:

hi,

yes context name is apex.

Good to know.


  https://xyz.ae/apex/f?p=1001  to
https://xyz.ae/apex/myapp  

we dont want to change xyz.ae that will name remain as it is , we want to
change f?p=1001  to myapp


Sorry, I don't understand, what you meant by the above.

I suspect, that you wanted to show, what the user enters into the 
browser and where the application listens. But it doesn't really makes 
sense to me.


Reading your first mail again, I think, that you have a loadbalancer 
that listens on xyz.ae and that proxies to xyz.com (you mentioned port 
8080, which is left out in all your examples). Is that right?


Apart from that, I wanted to know, what you tried on a technical level. 
Have you tried the curl command that I gave as an example?


Felix




On Wed, 23 Mar 2022 at 19:23, Felix Schumacher <
felix.schumac...@internetallee.de> wrote:



Am 23. März 2022 12:14:25 MEZ schrieb rupali singh <
rupali.r.si...@gmail.com>:

Hi Chris,

I already tried with fully qualified name but its not working

Can you be more specific, what you tried?

Is Chris right and your context name is apex?

Felix

On Tue, Mar 22, 2022, 7:15 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


All,

On 3/21/22 10:19, Felix Schumacher wrote:

Am 21.03.22 um 06:39 schrieb rupali singh:

Hi Felix,

location of context.xml file is

   cat context.xml| grep RewriteValve
  
className="org.apache.catalina.valves.rewrite.RewriteValve"

/>

   pwd
/opt/tomcat/apache-tomcat-9.0.54/instance/conf

That context.xml is thought to be a default template for all installed
webapps. It will work, but remember, that every installed webapp will
get its own copy of a rewrite valve.

+1

This is probably the problem.


more


/opt/tomcat/apache-tomcat-9.0.54/instance/webapps/ROOT/WEB-INF/rewrite.config

RewriteCond %{QUERY_STRING} p=10001
RewriteRule ^/apex/f$ /apex/myapp [R,L]


I think you want:

RewriteCond %{QUERY_STRING} p=10001
RewriteRule ^/f$ /myapp [R,L]

The prefix /apex is already a part of the context-path and should be
removed from the URL patterns being matched. If you want to redirect to
another web application, you need a fully-qualified redirect like this:

RewriteCond %{QUERY_STRING} p=10001
RewriteRule ^/f$https://www.google.com/  [R,L]

-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




OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Fwd: tomcat 9.50 - rewrite rule question

[rupali singh]

hi,

yes context name is apex.

 https://xyz.ae/apex/f?p=1001    to
https://xyz.ae/apex/myapp 

we dont want to change xyz.ae that will name remain as it is , we want to
change f?p=1001  to myapp



On Wed, 23 Mar 2022 at 19:23, Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

>
>
> Am 23. März 2022 12:14:25 MEZ schrieb rupali singh <
> rupali.r.si...@gmail.com>:
> >Hi Chris,
> >
> >I already tried with fully qualified name but its not working
>
> Can you be more specific, what you tried?
>
> Is Chris right and your context name is apex?
>
> Felix
> >
> >On Tue, Mar 22, 2022, 7:15 PM Christopher Schultz <
> >ch...@christopherschultz.net> wrote:
> >
> >> All,
> >>
> >> On 3/21/22 10:19, Felix Schumacher wrote:
> >> >
> >> > Am 21.03.22 um 06:39 schrieb rupali singh:
> >> >> Hi Felix,
> >> >>
> >> >> location of context.xml file is
> >> >>
> >> >>   cat context.xml| grep RewriteValve
> >> >>   className="org.apache.catalina.valves.rewrite.RewriteValve"
> >> />
> >> >>   pwd
> >> >> /opt/tomcat/apache-tomcat-9.0.54/instance/conf
> >> > That context.xml is thought to be a default template for all installed
> >> > webapps. It will work, but remember, that every installed webapp will
> >> > get its own copy of a rewrite valve.
> >>
> >> +1
> >>
> >> This is probably the problem.
> >>
> >> >> more
> >> >>
> >>
> /opt/tomcat/apache-tomcat-9.0.54/instance/webapps/ROOT/WEB-INF/rewrite.config
> >> >> RewriteCond %{QUERY_STRING} p=10001
> >> >> RewriteRule ^/apex/f$ /apex/myapp [R,L]
> >>
> >>
> >> I think you want:
> >>
> >> RewriteCond %{QUERY_STRING} p=10001
> >> RewriteRule ^/f$ /myapp [R,L]
> >>
> >> The prefix /apex is already a part of the context-path and should be
> >> removed from the URL patterns being matched. If you want to redirect to
> >> another web application, you need a fully-qualified redirect like this:
> >>
> >> RewriteCond %{QUERY_STRING} p=10001
> >> RewriteRule ^/f$ https://www.google.com/ [R,L]
> >>
> >> -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
>
>

-- 
Thanks and Regards,
Rupali

Re: Fwd: tomcat 9.50 - rewrite rule question

[Felix Schumacher]

Am 23. März 2022 12:14:25 MEZ schrieb rupali singh :
>Hi Chris,
>
>I already tried with fully qualified name but its not working

Can you be more specific, what you tried?

Is Chris right and your context name is apex? 

Felix
>
>On Tue, Mar 22, 2022, 7:15 PM Christopher Schultz <
>ch...@christopherschultz.net> wrote:
>
>> All,
>>
>> On 3/21/22 10:19, Felix Schumacher wrote:
>> >
>> > Am 21.03.22 um 06:39 schrieb rupali singh:
>> >> Hi Felix,
>> >>
>> >> location of context.xml file is
>> >>
>> >>   cat context.xml| grep RewriteValve
>> >>  > />
>> >>   pwd
>> >> /opt/tomcat/apache-tomcat-9.0.54/instance/conf
>> > That context.xml is thought to be a default template for all installed
>> > webapps. It will work, but remember, that every installed webapp will
>> > get its own copy of a rewrite valve.
>>
>> +1
>>
>> This is probably the problem.
>>
>> >> more
>> >>
>> /opt/tomcat/apache-tomcat-9.0.54/instance/webapps/ROOT/WEB-INF/rewrite.config
>> >> RewriteCond %{QUERY_STRING} p=10001
>> >> RewriteRule ^/apex/f$ /apex/myapp [R,L]
>>
>>
>> I think you want:
>>
>> RewriteCond %{QUERY_STRING} p=10001
>> RewriteRule ^/f$ /myapp [R,L]
>>
>> The prefix /apex is already a part of the context-path and should be
>> removed from the URL patterns being matched. If you want to redirect to
>> another web application, you need a fully-qualified redirect like this:
>>
>> RewriteCond %{QUERY_STRING} p=10001
>> RewriteRule ^/f$ https://www.google.com/ [R,L]
>>
>> -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: Fwd: tomcat 9.50 - rewrite rule question

[rupali singh]

Hi Chris,

I already tried with fully qualified name but its not working

On Tue, Mar 22, 2022, 7:15 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> All,
>
> On 3/21/22 10:19, Felix Schumacher wrote:
> >
> > Am 21.03.22 um 06:39 schrieb rupali singh:
> >> Hi Felix,
> >>
> >> location of context.xml file is
> >>
> >>   cat context.xml| grep RewriteValve
> >>   />
> >>   pwd
> >> /opt/tomcat/apache-tomcat-9.0.54/instance/conf
> > That context.xml is thought to be a default template for all installed
> > webapps. It will work, but remember, that every installed webapp will
> > get its own copy of a rewrite valve.
>
> +1
>
> This is probably the problem.
>
> >> more
> >>
> /opt/tomcat/apache-tomcat-9.0.54/instance/webapps/ROOT/WEB-INF/rewrite.config
> >> RewriteCond %{QUERY_STRING} p=10001
> >> RewriteRule ^/apex/f$ /apex/myapp [R,L]
>
>
> I think you want:
>
> RewriteCond %{QUERY_STRING} p=10001
> RewriteRule ^/f$ /myapp [R,L]
>
> The prefix /apex is already a part of the context-path and should be
> removed from the URL patterns being matched. If you want to redirect to
> another web application, you need a fully-qualified redirect like this:
>
> RewriteCond %{QUERY_STRING} p=10001
> RewriteRule ^/f$ https://www.google.com/ [R,L]
>
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Fwd: tomcat 9.50 - rewrite rule question

[Christopher Schultz]

All,

On 3/21/22 10:19, Felix Schumacher wrote:


Am 21.03.22 um 06:39 schrieb rupali singh:

Hi Felix,

location of context.xml file is

  cat context.xml| grep RewriteValve
 
  pwd
/opt/tomcat/apache-tomcat-9.0.54/instance/conf
That context.xml is thought to be a default template for all installed 
webapps. It will work, but remember, that every installed webapp will 
get its own copy of a rewrite valve.


+1

This is probably the problem.


more
/opt/tomcat/apache-tomcat-9.0.54/instance/webapps/ROOT/WEB-INF/rewrite.config
RewriteCond %{QUERY_STRING} p=10001
RewriteRule ^/apex/f$ /apex/myapp [R,L]



I think you want:

RewriteCond %{QUERY_STRING} p=10001
RewriteRule ^/f$ /myapp [R,L]

The prefix /apex is already a part of the context-path and should be 
removed from the URL patterns being matched. If you want to redirect to 
another web application, you need a fully-qualified redirect like this:


RewriteCond %{QUERY_STRING} p=10001
RewriteRule ^/f$ https://www.google.com/ [R,L]

-chris

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

Re: Fwd: tomcat 9.50 - rewrite rule question

[Felix Schumacher]

Am 21.03.22 um 06:39 schrieb rupali singh:

Hi Felix,

location of context.xml file is

  cat context.xml| grep RewriteValve
 
  pwd
/opt/tomcat/apache-tomcat-9.0.54/instance/conf
That context.xml is thought to be a default template for all installed 
webapps. It will work, but remember, that every installed webapp will 
get its own copy of a rewrite valve.




more
/opt/tomcat/apache-tomcat-9.0.54/instance/webapps/ROOT/WEB-INF/rewrite.config
RewriteCond %{QUERY_STRING} p=10001
RewriteRule ^/apex/f$ /apex/myapp [R,L]


What happens, when you call the apex URL with curl? Something like

> curl -D- 'localhost:8080/apex/f?p=10001'

It should display (assuming your tomcat listens on port 8080) something 
like:


HTTP/1.1 302
Location: /apex/myapp?p=10001
Content-Length: 0
Date: Mon, 21 Mar 2022 ...

Felix



its still not working


On Mon, 21 Mar 2022 at 00:57, Felix Schumacher <
felix.schumac...@internetallee.de> wrote:


Am 20.03.22 um 19:45 schrieb Thomas Hoffmann (Speed4Trade GmbH):

Hello,

url rewrite doesn't match against url parameters as far as I know.
RewriteRule ^/apex/f$  /apex/myapp [R,L]

You can match the query string by adding a RewriteCond, for example

RewriteCond %{QUERY_STRING} p=1001
RewriteRule ^/apex/f$ /apex/myapp [R,L]

(The lines have to be in that order and no other line in between)

Felix

Just a guess, maybe you can  give it a try.

Another option would be to use the source code of tomcat and set a breakpoint 
within the filter class
(just with a little dummy app deployed).

Greetings, Thomas


-Ursprüngliche Nachricht-
Von: rupali singh  
Gesendet: Sonntag, 20. März 2022 19:23
An: Tomcat Users List  
Betreff: Re: Fwd: tomcat 9.50 - rewrite rule question

Hi,

i have referred Around 
here:https://tomcat.apache.org/tomcat-9.0-doc/rewrite.html#RewriteRule
but still can't figure out how to write rules for my requirements..
can you please help

On Sat, 19 Mar 2022 at 21:57, Thomas Hoffmann (Speed4Trade 
GmbH)  
  wrote:


Hallo,

just scroll down the documentation.
Around here:https://tomcat.apache.org/tomcat-9.0-doc/rewrite.html#RewriteRule
If something is not clear there, just drop a line



-Ursprüngliche Nachricht-
Von: rupali singh  
Gesendet: Samstag, 19. März 2022 18:28
An: Tomcat Users List  
Betreff: Re: Fwd: tomcat 9.50 - rewrite rule question

Hi,

Thanks a lot for your quick response.then what options we have in
tomcat apache for rewrite rules.

Apologies im new to apache tomcat.


On Sat, Mar 19, 2022, 9:42 PM Terence M. Bandoian  

wrote:


On 3/19/2022 1:03 AM, rupali singh wrote:

Hi Team,

We are using tomcat 9.54 version.
Need help in rewriting rule.

background   : We have an Oracle apex server ( version 21.1)  and

tomcat

is

installed on the same server. We have F5 url which redirects to
apex installed on tomcat  
eghttps://xyz.ae/apex/f?p=1001<https://xyz.com/apex/f?p=1001>  
<https://xyz.com/apex/f?p=1001>so xyz.ae is published on our F5

which

redirects internally to tomcat server on port 8080.

we want to redirecthttps://xyz.ae/apex/f?p=1001<https://xyz.com/apex/f?p=1001>  
<https://xyz.com/apex/f?p=1001>to
   https://xyz.ae/apex/myapp  <https://xyz.com/aorx/myapp>  
<https://xyz.com/aorx/myapp>as it's

difficult

for business users to remember f?p=1001<https://xyz.com/apex/f?p=1001>  
<https://xyz.com/apex/f?p=1001>

i have prepared context.xml and rewrite.config rule but
redirection not working and there is no error in catalina.log

in access log we are getting 404.

i have tried steps mentioned in


https://stackoverflow.com/questions/38618473/tomcat-9-rewrite-with
-

ord

s-and-oracle-apex

rewrite.config content

RewriteCond %{REQUEST_URI} ^/myapp$ RewriteRule 
^/myapp$https://xyz.ae/apex/myapp  [R,L]


please advise how to resolve the issue

Those look like Apache HTTPD rewrite rules. How are they supported
in Apache Tomcat?

-Terence Bandoian


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

  --
Thanks and Regards,
Rupali

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




OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Fwd: tomcat 9.50 - rewrite rule question

[rupali singh]

Hi Felix,

location of context.xml file is

 cat context.xml| grep RewriteValve

 pwd
/opt/tomcat/apache-tomcat-9.0.54/instance/conf



more
/opt/tomcat/apache-tomcat-9.0.54/instance/webapps/ROOT/WEB-INF/rewrite.config
RewriteCond %{QUERY_STRING} p=10001
RewriteRule ^/apex/f$ /apex/myapp [R,L]

its still not working


On Mon, 21 Mar 2022 at 00:57, Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

>
> Am 20.03.22 um 19:45 schrieb Thomas Hoffmann (Speed4Trade GmbH):
>
> Hello,
>
> url rewrite doesn't match against url parameters as far as I know.
> RewriteRule ^/apex/f$  /apex/myapp [R,L]
>
> You can match the query string by adding a RewriteCond, for example
>
> RewriteCond %{QUERY_STRING} p=1001
> RewriteRule ^/apex/f$ /apex/myapp [R,L]
>
> (The lines have to be in that order and no other line in between)
>
> Felix
>
> Just a guess, maybe you can  give it a try.
>
> Another option would be to use the source code of tomcat and set a breakpoint 
> within the filter class
> (just with a little dummy app deployed).
>
> Greetings, Thomas
>
>
> -Ursprüngliche Nachricht-
> Von: rupali singh  
> Gesendet: Sonntag, 20. März 2022 19:23
> An: Tomcat Users List  
> Betreff: Re: Fwd: tomcat 9.50 - rewrite rule question
>
> Hi,
>
> i have referred Around 
> here:https://tomcat.apache.org/tomcat-9.0-doc/rewrite.html#RewriteRule
> but still can't figure out how to write rules for my requirements..
> can you please help
>
> On Sat, 19 Mar 2022 at 21:57, Thomas Hoffmann (Speed4Trade 
> GmbH) 
>  wrote:
>
>
> Hallo,
>
> just scroll down the documentation.
> Around here:https://tomcat.apache.org/tomcat-9.0-doc/rewrite.html#RewriteRule
> If something is not clear there, just drop a line
>
>
>
> -Ursprüngliche Nachricht-
> Von: rupali singh  
> Gesendet: Samstag, 19. März 2022 18:28
> An: Tomcat Users List  
> Betreff: Re: Fwd: tomcat 9.50 - rewrite rule question
>
> Hi,
>
> Thanks a lot for your quick response.then what options we have in
> tomcat apache for rewrite rules.
>
> Apologies im new to apache tomcat.
>
>
> On Sat, Mar 19, 2022, 9:42 PM Terence M. Bandoian 
> 
> wrote:
>
>
> On 3/19/2022 1:03 AM, rupali singh wrote:
>
> Hi Team,
>
> We are using tomcat 9.54 version.
> Need help in rewriting rule.
>
> background   : We have an Oracle apex server ( version 21.1)  and
>
> tomcat
>
> is
>
> installed on the same server. We have F5 url which redirects to
> apex installed on tomcat  eg 
> https://xyz.ae/apex/f?p=1001<https://xyz.com/apex/f?p=1001> 
> <https://xyz.com/apex/f?p=1001>   so xyz.ae is published on our F5
>
> which
>
> redirects internally to tomcat server on port 8080.
>
> we want to redirect  
> https://xyz.ae/apex/f?p=1001<https://xyz.com/apex/f?p=1001> 
> <https://xyz.com/apex/f?p=1001>   to
>   https://xyz.ae/apex/myapp <https://xyz.com/aorx/myapp> 
> <https://xyz.com/aorx/myapp>   as it's
>
> difficult
>
> for business users to remember f?p=1001<https://xyz.com/apex/f?p=1001> 
> <https://xyz.com/apex/f?p=1001>
>
> i have prepared context.xml and rewrite.config rule but
> redirection not working and there is no error in catalina.log
>
> in access log we are getting 404.
>
> i have tried steps mentioned in
>
>
> https://stackoverflow.com/questions/38618473/tomcat-9-rewrite-with
> -
>
> ord
>
> s-and-oracle-apex
>
> rewrite.config content
>
> RewriteCond %{REQUEST_URI} ^/myapp$ RewriteRule 
> ^/myapp$https://xyz.ae/apex/myapp [R,L]
>
>
> please advise how to resolve the issue
>
> Those look like Apache HTTPD rewrite rules. How are they supported
> in Apache Tomcat?
>
> -Terence Bandoian
>
>
> --
> --- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>  --
> Thanks and Regards,
> Rupali
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-- 
Thanks and Regards,
Rupali

Re: Fwd: tomcat 9.50 - rewrite rule question

[Felix Schumacher]

Am 20.03.22 um 19:45 schrieb Thomas Hoffmann (Speed4Trade GmbH):

Hello,

url rewrite doesn't match against url parameters as far as I know.
RewriteRule ^/apex/f$  /apex/myapp [R,L]


You can match the query string by adding a RewriteCond, for example

RewriteCond %{QUERY_STRING} p=1001
RewriteRule ^/apex/f$ /apex/myapp [R,L]

(The lines have to be in that order and no other line in between)

Felix



Just a guess, maybe you can  give it a try.

Another option would be to use the source code of tomcat and set a breakpoint 
within the filter class
(just with a little dummy app deployed).

Greetings, Thomas


-Ursprüngliche Nachricht-
Von: rupali singh
Gesendet: Sonntag, 20. März 2022 19:23
An: Tomcat Users List
Betreff: Re: Fwd: tomcat 9.50 - rewrite rule question

Hi,

i have referred Around here:
https://tomcat.apache.org/tomcat-9.0-doc/rewrite.html#RewriteRule
but still can't figure out how to write rules for my requirements..
can you please help

On Sat, 19 Mar 2022 at 21:57, Thomas Hoffmann (Speed4Trade GmbH)
  wrote:


Hallo,

just scroll down the documentation.
Around here:
https://tomcat.apache.org/tomcat-9.0-doc/rewrite.html#RewriteRule
If something is not clear there, just drop a line



-Ursprüngliche Nachricht-
Von: rupali singh
Gesendet: Samstag, 19. März 2022 18:28
An: Tomcat Users List
Betreff: Re: Fwd: tomcat 9.50 - rewrite rule question

Hi,

Thanks a lot for your quick response.then what options we have in
tomcat apache for rewrite rules.

Apologies im new to apache tomcat.


On Sat, Mar 19, 2022, 9:42 PM Terence M. Bandoian

wrote:


On 3/19/2022 1:03 AM, rupali singh wrote:

Hi Team,

We are using tomcat 9.54 version.
Need help in rewriting rule.

background   : We have an Oracle apex server ( version 21.1)  and

tomcat

is

installed on the same server. We have F5 url which redirects to
apex installed on tomcat  eghttps://xyz.ae/apex/f?p=1001
<https://xyz.com/apex/f?p=1001>so xyz.ae is published on our F5

which

redirects internally to tomcat server on port 8080.

we want to redirecthttps://xyz.ae/apex/f?p=1001
<https://xyz.com/apex/f?p=1001>to
   https://xyz.ae/apex/myapp  <https://xyz.com/aorx/myapp>as it's

difficult

for business users to remember f?p=1001
<https://xyz.com/apex/f?p=1001>

i have prepared context.xml and rewrite.config rule but
redirection not working and there is no error in catalina.log

in access log we are getting 404.

i have tried steps mentioned in


https://stackoverflow.com/questions/38618473/tomcat-9-rewrite-with
-

ord

s-and-oracle-apex

rewrite.config content

RewriteCond %{REQUEST_URI} ^/myapp$ RewriteRule ^/myapp$
https://xyz.ae/apex/myapp  [R,L]


please advise how to resolve the issue

Those look like Apache HTTPD rewrite rules. How are they supported
in Apache Tomcat?

-Terence Bandoian


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




--
Thanks and Regards,
Rupali

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



OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Fwd: tomcat 9.50 - rewrite rule question

[Felix Schumacher]

Am 20.03.22 um 20:17 schrieb rupali singh:

Hi Thomas,
thanks for the quick reply.
I have tried below but it's still not working.

RewriteRule ^/apex/f$  /apex/myapp [R,L]

I have placed rewrite.config on below locations and fileis same in both
locations , after changing rewrite.config i'm restarting tomcat as well.
/opt/tomcat/apache-tomcat-9.0.54/instance/webapps/ROOT/WEB-INF/rewrite.config
and
/opt/tomcat/apache-tomcat-9.0.54/instance/webapps/apex/WEB-INF/rewrite.config


Have you added the RewriteValve to your context.xml? And if so, are you 
sure, that it is the one, that tomcat uses?


Where did you place context.xml and have you checked 
Catalina/localhost/apex.xml has not been copied earlier?


Felix




i'm new to apache tomcat and now aware of how to achieve below.


Another option would be to use the source code of tomcat and set a
breakpoint within the filter class
(just with a little dummy app deployed).

On Sun, 20 Mar 2022 at 22:46, Thomas Hoffmann (Speed4Trade GmbH)
  wrote:


Hello,

url rewrite doesn't match against url parameters as far as I know.
RewriteRule ^/apex/f$  /apex/myapp [R,L]

Just a guess, maybe you can  give it a try.

Another option would be to use the source code of tomcat and set a
breakpoint within the filter class
(just with a little dummy app deployed).

Greetings, Thomas


-Ursprüngliche Nachricht-
Von: rupali singh
Gesendet: Sonntag, 20. März 2022 19:23
An: Tomcat Users List
Betreff: Re: Fwd: tomcat 9.50 - rewrite rule question

Hi,

i have referred Around here:
https://tomcat.apache.org/tomcat-9.0-doc/rewrite.html#RewriteRule
but still can't figure out how to write rules for my requirements..
can you please help

On Sat, 19 Mar 2022 at 21:57, Thomas Hoffmann (Speed4Trade GmbH)
  wrote:


Hallo,

just scroll down the documentation.
Around here:
https://tomcat.apache.org/tomcat-9.0-doc/rewrite.html#RewriteRule
If something is not clear there, just drop a line



-Ursprüngliche Nachricht-
Von: rupali singh
Gesendet: Samstag, 19. März 2022 18:28
An: Tomcat Users List
Betreff: Re: Fwd: tomcat 9.50 - rewrite rule question

Hi,

Thanks a lot for your quick response.then what options we have in
tomcat apache for rewrite rules.

Apologies im new to apache tomcat.


On Sat, Mar 19, 2022, 9:42 PM Terence M. Bandoian

wrote:


On 3/19/2022 1:03 AM, rupali singh wrote:

Hi Team,

We are using tomcat 9.54 version.
Need help in rewriting rule.

background   : We have an Oracle apex server ( version 21.1)  and

tomcat

is

installed on the same server. We have F5 url which redirects to
apex installed on tomcat  eghttps://xyz.ae/apex/f?p=1001
<https://xyz.com/apex/f?p=1001>so xyz.ae is published on our

F5

which

redirects internally to tomcat server on port 8080.

we want to redirecthttps://xyz.ae/apex/f?p=1001
<https://xyz.com/apex/f?p=1001>to
   https://xyz.ae/apex/myapp  <https://xyz.com/aorx/myapp>as

it's

difficult

for business users to remember f?p=1001
<https://xyz.com/apex/f?p=1001>

i have prepared context.xml and rewrite.config rule but
redirection not working and there is no error in catalina.log

in access log we are getting 404.

i have tried steps mentioned in


https://stackoverflow.com/questions/38618473/tomcat-9-rewrite-with
-

ord

s-and-oracle-apex

rewrite.config content

RewriteCond %{REQUEST_URI} ^/myapp$ RewriteRule ^/myapp$
https://xyz.ae/apex/myapp  [R,L]


please advise how to resolve the issue

Those look like Apache HTTPD rewrite rules. How are they supported
in Apache Tomcat?

-Terence Bandoian


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




--
Thanks and Regards,
Rupali




OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Fwd: tomcat 9.50 - rewrite rule question

[Felix Schumacher]

Am 19.03.22 um 07:03 schrieb rupali singh:

Hi Team,

We are using tomcat 9.54 version.
Need help in rewriting rule.

background   : We have an Oracle apex server ( version 21.1)  and tomcat is
installed on the same server. We have F5 url which redirects to apex
installed on tomcat  eghttps://xyz.ae/apex/f?p=1001
so xyz.ae is published on our F5 which
redirects internally to tomcat server on port 8080.

we want to redirecthttps://xyz.ae/apex/f?p=1001
to
  https://xyz.ae/apex/myapp  as it's difficult
for business users to remember f?p=1001


Are you sure, that you want to redirect the obscure URL - that is hard 
to remember - to redirect to a "sane" URL - that is easy to remember? I 
would do it the other way round. Tell the people to enter 
https://apex.ae/myapp (or apex.com/myapp) and let the app rewrite it to 
something hard to remember.


Felix



i have prepared context.xml and rewrite.config rule but redirection not
working and there is no error in catalina.log

in access log we are getting 404.

i have tried steps mentioned in
https://stackoverflow.com/questions/38618473/tomcat-9-rewrite-with-ords-and-oracle-apex

rewrite.config content

RewriteCond %{REQUEST_URI} ^/myapp$
RewriteRule ^/myapp$https://xyz.ae/apex/myapp  [R,L]


please advise how to resolve the issue


OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Fwd: tomcat 9.50 - rewrite rule question

[rupali singh]

Hi,

Yes im restarting the tomcat after changing the rewrite. Config file.


i have increased log level to FINE


*cat /opt/tomcat/apache-tomcat-9.0.54/instance/conf/logging.properties |
grep FINE*
1catalina.org.apache.juli.AsyncFileHandler.level = FINE
2localhost.org.apache.juli.AsyncFileHandler.level = FINE
3manager.org.apache.juli.AsyncFileHandler.level = FINE
4host-manager.org.apache.juli.AsyncFileHandler.level = FINE
java.util.logging.ConsoleHandler.level = FINE
*org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level = FINE*
#org.apache.catalina.util.LifecycleBase.level = FINE
#org.apache.jasper.compiler.TldLocationsCache.level = FINE
#org.apache.coyote.http2.level = FINE
#org.apache.tomcat.websocket.level = FINE


in which log file it will write detailed errors/issues/ trace details

i have checked below files but cant see anything related to rewrite rules.
its all normal logs only

catalina.out
catalina.2022-03-20.log
localhost_access_log.2022-03-20.txt


 cat localhost_access_log.2022-03-20.txt | grep myapp
x.x.x.x - - [20/Mar/2022:20:08:47 +] "GET /apex/myapp HTTP/1.1" 404
16681





On Mon, Mar 21, 2022, 1:25 AM Thomas Hoffmann (Speed4Trade GmbH)
 wrote:

> Hello,
>
> the location under /WEB-INF/ is the correct one.
> Did you restart tomcat afterwards? The config is loaded during startup.
>
> Maybe you can activate logging via logging.properties
>
> org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level = FINE
>
> Should spit out plenty of information in one of the logfiles.
>
>
> > -Ursprüngliche Nachricht-
> > Von: rupali singh 
> > Gesendet: Sonntag, 20. März 2022 20:17
> > An: Tomcat Users List 
> > Betreff: Re: Fwd: tomcat 9.50 - rewrite rule question
> >
> > Hi Thomas,
> > thanks for the quick reply.
> > I have tried below but it's still not working.
> >
> > RewriteRule ^/apex/f$  /apex/myapp [R,L]
> >
> > I have placed rewrite.config on below locations and fileis same in both
> > locations , after changing rewrite.config i'm restarting tomcat as well.
> > /opt/tomcat/apache-tomcat-9.0.54/instance/webapps/ROOT/WEB-
> > INF/rewrite.config
> > and
> > /opt/tomcat/apache-tomcat-9.0.54/instance/webapps/apex/WEB-
> > INF/rewrite.config
> >
> >
> > i'm new to apache tomcat and now aware of how to achieve below.
> >
> >
> > Another option would be to use the source code of tomcat and set a
> > breakpoint within the filter class (just with a little dummy app
> deployed).
> >
> > On Sun, 20 Mar 2022 at 22:46, Thomas Hoffmann (Speed4Trade GmbH)
> >  wrote:
> >
> > > Hello,
> > >
> > > url rewrite doesn't match against url parameters as far as I know.
> > > RewriteRule ^/apex/f$  /apex/myapp [R,L]
> > >
> > > Just a guess, maybe you can  give it a try.
> > >
> > > Another option would be to use the source code of tomcat and set a
> > > breakpoint within the filter class (just with a little dummy app
> > > deployed).
> > >
> > > Greetings, Thomas
> > >
> > > > -Ursprüngliche Nachricht-
> > > > Von: rupali singh 
> > > > Gesendet: Sonntag, 20. März 2022 19:23
> > > > An: Tomcat Users List 
> > > > Betreff: Re: Fwd: tomcat 9.50 - rewrite rule question
> > > >
> > > > Hi,
> > > >
> > > > i have referred Around here:
> > > > https://tomcat.apache.org/tomcat-9.0-doc/rewrite.html#RewriteRule
> > > > but still can't figure out how to write rules for my requirements..
> > > > can you please help
> > > >
> > > > On Sat, 19 Mar 2022 at 21:57, Thomas Hoffmann (Speed4Trade GmbH)
> > > >  wrote:
> > > >
> > > > > Hallo,
> > > > >
> > > > > just scroll down the documentation.
> > > > > Around here:
> > > > > https://tomcat.apache.org/tomcat-9.0-doc/rewrite.html#RewriteRule
> > > > > If something is not clear there, just drop a line
> > > > >
> > > > >
> > > > > > -Ursprüngliche Nachricht-
> > > > > > Von: rupali singh 
> > > > > > Gesendet: Samstag, 19. März 2022 18:28
> > > > > > An: Tomcat Users List 
> > > > > > Betreff: Re: Fwd: tomcat 9.50 - rewrite rule question
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Thanks a lot for your quick response.then what options we have
> > > > > > in tomcat apache 

Re: Fwd: tomcat 9.50 - rewrite rule question

[rupali singh]

Hi Thomas,
thanks for the quick reply.
I have tried below but it's still not working.

RewriteRule ^/apex/f$  /apex/myapp [R,L]

I have placed rewrite.config on below locations and fileis same in both
locations , after changing rewrite.config i'm restarting tomcat as well.
/opt/tomcat/apache-tomcat-9.0.54/instance/webapps/ROOT/WEB-INF/rewrite.config
and
/opt/tomcat/apache-tomcat-9.0.54/instance/webapps/apex/WEB-INF/rewrite.config


i'm new to apache tomcat and now aware of how to achieve below.


Another option would be to use the source code of tomcat and set a
breakpoint within the filter class
(just with a little dummy app deployed).

On Sun, 20 Mar 2022 at 22:46, Thomas Hoffmann (Speed4Trade GmbH)
 wrote:

> Hello,
>
> url rewrite doesn't match against url parameters as far as I know.
> RewriteRule ^/apex/f$  /apex/myapp [R,L]
>
> Just a guess, maybe you can  give it a try.
>
> Another option would be to use the source code of tomcat and set a
> breakpoint within the filter class
> (just with a little dummy app deployed).
>
> Greetings, Thomas
>
> > -Ursprüngliche Nachricht-
> > Von: rupali singh 
> > Gesendet: Sonntag, 20. März 2022 19:23
> > An: Tomcat Users List 
> > Betreff: Re: Fwd: tomcat 9.50 - rewrite rule question
> >
> > Hi,
> >
> > i have referred Around here:
> > https://tomcat.apache.org/tomcat-9.0-doc/rewrite.html#RewriteRule
> > but still can't figure out how to write rules for my requirements..
> > can you please help
> >
> > On Sat, 19 Mar 2022 at 21:57, Thomas Hoffmann (Speed4Trade GmbH)
> >  wrote:
> >
> > > Hallo,
> > >
> > > just scroll down the documentation.
> > > Around here:
> > > https://tomcat.apache.org/tomcat-9.0-doc/rewrite.html#RewriteRule
> > > If something is not clear there, just drop a line
> > >
> > >
> > > > -Ursprüngliche Nachricht-
> > > > Von: rupali singh 
> > > > Gesendet: Samstag, 19. März 2022 18:28
> > > > An: Tomcat Users List 
> > > > Betreff: Re: Fwd: tomcat 9.50 - rewrite rule question
> > > >
> > > > Hi,
> > > >
> > > > Thanks a lot for your quick response.then what options we have in
> > > > tomcat apache for rewrite rules.
> > > >
> > > > Apologies im new to apache tomcat.
> > > >
> > > >
> > > > On Sat, Mar 19, 2022, 9:42 PM Terence M. Bandoian
> > > > 
> > > > wrote:
> > > >
> > > > > On 3/19/2022 1:03 AM, rupali singh wrote:
> > > > > > Hi Team,
> > > > > >
> > > > > > We are using tomcat 9.54 version.
> > > > > > Need help in rewriting rule.
> > > > > >
> > > > > > background   : We have an Oracle apex server ( version 21.1)  and
> > > tomcat
> > > > > is
> > > > > > installed on the same server. We have F5 url which redirects to
> > > > > > apex installed on tomcat  eg https://xyz.ae/apex/f?p=1001
> > > > > > <https://xyz.com/apex/f?p=1001>   so xyz.ae is published on our
> F5
> > > > which
> > > > > > redirects internally to tomcat server on port 8080.
> > > > > >
> > > > > > we want to redirect  https://xyz.ae/apex/f?p=1001
> > > > > > <https://xyz.com/apex/f?p=1001>   to
> > > > > >   https://xyz.ae/apex/myapp <https://xyz.com/aorx/myapp>   as
> it's
> > > > > difficult
> > > > > > for business users to remember f?p=1001
> > > > > > <https://xyz.com/apex/f?p=1001>
> > > > > >
> > > > > > i have prepared context.xml and rewrite.config rule but
> > > > > > redirection not working and there is no error in catalina.log
> > > > > >
> > > > > > in access log we are getting 404.
> > > > > >
> > > > > > i have tried steps mentioned in
> > > > > >
> > > > > https://stackoverflow.com/questions/38618473/tomcat-9-rewrite-with
> > > > > -
> > > > ord
> > > > > s-and-oracle-apex
> > > > > >
> > > > > > rewrite.config content
> > > > > >
> > > > > > RewriteCond %{REQUEST_URI} ^/myapp$ RewriteRule ^/myapp$
> > > > > > https://xyz.ae/apex/myapp [R,L]
> > > > > >
> > > > > >
> > > > > > please advise how to resolve the issue
> > > > >
> > > > > Those look like Apache HTTPD rewrite rules. How are they supported
> > > > > in Apache Tomcat?
> > > > >
> > > > > -Terence Bandoian
> > > > >
> > > > >
> > > > > --
> > > > > --- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > > > > For additional commands, e-mail: users-h...@tomcat.apache.org
> > > > >
> > > > >
> > >
> >
> >
> > --
> > Thanks and Regards,
> > Rupali
>


-- 
Thanks and Regards,
Rupali

Re: Fwd: tomcat 9.50 - rewrite rule question

[rupali singh]

Hi,

i have referred Around here:
https://tomcat.apache.org/tomcat-9.0-doc/rewrite.html#RewriteRule
but still can't figure out how to write rules for my requirements..
can you please help

On Sat, 19 Mar 2022 at 21:57, Thomas Hoffmann (Speed4Trade GmbH)
 wrote:

> Hallo,
>
> just scroll down the documentation.
> Around here:
> https://tomcat.apache.org/tomcat-9.0-doc/rewrite.html#RewriteRule
> If something is not clear there, just drop a line
>
>
> > -Ursprüngliche Nachricht-
> > Von: rupali singh 
> > Gesendet: Samstag, 19. März 2022 18:28
> > An: Tomcat Users List 
> > Betreff: Re: Fwd: tomcat 9.50 - rewrite rule question
> >
> > Hi,
> >
> > Thanks a lot for your quick response.then what options we have in tomcat
> > apache for rewrite rules.
> >
> > Apologies im new to apache tomcat.
> >
> >
> > On Sat, Mar 19, 2022, 9:42 PM Terence M. Bandoian 
> > wrote:
> >
> > > On 3/19/2022 1:03 AM, rupali singh wrote:
> > > > Hi Team,
> > > >
> > > > We are using tomcat 9.54 version.
> > > > Need help in rewriting rule.
> > > >
> > > > background   : We have an Oracle apex server ( version 21.1)  and
> tomcat
> > > is
> > > > installed on the same server. We have F5 url which redirects to apex
> > > > installed on tomcat  eg https://xyz.ae/apex/f?p=1001
> > > > <https://xyz.com/apex/f?p=1001>   so xyz.ae is published on our F5
> > which
> > > > redirects internally to tomcat server on port 8080.
> > > >
> > > > we want to redirect  https://xyz.ae/apex/f?p=1001
> > > > <https://xyz.com/apex/f?p=1001>   to
> > > >   https://xyz.ae/apex/myapp <https://xyz.com/aorx/myapp>   as it's
> > > difficult
> > > > for business users to remember f?p=1001
> > > > <https://xyz.com/apex/f?p=1001>
> > > >
> > > > i have prepared context.xml and rewrite.config rule but redirection
> > > > not working and there is no error in catalina.log
> > > >
> > > > in access log we are getting 404.
> > > >
> > > > i have tried steps mentioned in
> > > >
> > > https://stackoverflow.com/questions/38618473/tomcat-9-rewrite-with-
> > ord
> > > s-and-oracle-apex
> > > >
> > > > rewrite.config content
> > > >
> > > > RewriteCond %{REQUEST_URI} ^/myapp$
> > > > RewriteRule ^/myapp$ https://xyz.ae/apex/myapp [R,L]
> > > >
> > > >
> > > > please advise how to resolve the issue
> > >
> > > Those look like Apache HTTPD rewrite rules. How are they supported in
> > > Apache Tomcat?
> > >
> > > -Terence Bandoian
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > > For additional commands, e-mail: users-h...@tomcat.apache.org
> > >
> > >
>


-- 
Thanks and Regards,
Rupali

Re: Fwd: tomcat 9.50 - rewrite rule question

[rupali singh]

Hi,

Thanks a lot for your quick response.then what options we have in tomcat
apache for rewrite rules.

Apologies im new to apache tomcat.


On Sat, Mar 19, 2022, 9:42 PM Terence M. Bandoian  wrote:

> On 3/19/2022 1:03 AM, rupali singh wrote:
> > Hi Team,
> >
> > We are using tomcat 9.54 version.
> > Need help in rewriting rule.
> >
> > background   : We have an Oracle apex server ( version 21.1)  and tomcat
> is
> > installed on the same server. We have F5 url which redirects to apex
> > installed on tomcat  eg https://xyz.ae/apex/f?p=1001
> >    so xyz.ae is published on our F5 which
> > redirects internally to tomcat server on port 8080.
> >
> > we want to redirect  https://xyz.ae/apex/f?p=1001
> >    to
> >   https://xyz.ae/apex/myapp    as it's
> difficult
> > for business users to remember f?p=1001 
> >
> > i have prepared context.xml and rewrite.config rule but redirection not
> > working and there is no error in catalina.log
> >
> > in access log we are getting 404.
> >
> > i have tried steps mentioned in
> >
> https://stackoverflow.com/questions/38618473/tomcat-9-rewrite-with-ords-and-oracle-apex
> >
> > rewrite.config content
> >
> > RewriteCond %{REQUEST_URI} ^/myapp$
> > RewriteRule ^/myapp$ https://xyz.ae/apex/myapp [R,L]
> >
> >
> > please advise how to resolve the issue
>
> Those look like Apache HTTPD rewrite rules. How are they supported in
> Apache Tomcat?
>
> -Terence Bandoian
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Fwd: tomcat 9.50 - rewrite rule question

[Terence M. Bandoian]

On 3/19/2022 1:03 AM, rupali singh wrote:

Hi Team,

We are using tomcat 9.54 version.
Need help in rewriting rule.

background   : We have an Oracle apex server ( version 21.1)  and tomcat is
installed on the same server. We have F5 url which redirects to apex
installed on tomcat  eg https://xyz.ae/apex/f?p=1001
   so xyz.ae is published on our F5 which
redirects internally to tomcat server on port 8080.

we want to redirect  https://xyz.ae/apex/f?p=1001
   to
  https://xyz.ae/apex/myapp    as it's difficult
for business users to remember f?p=1001 

i have prepared context.xml and rewrite.config rule but redirection not
working and there is no error in catalina.log

in access log we are getting 404.

i have tried steps mentioned in
https://stackoverflow.com/questions/38618473/tomcat-9-rewrite-with-ords-and-oracle-apex

rewrite.config content

RewriteCond %{REQUEST_URI} ^/myapp$
RewriteRule ^/myapp$ https://xyz.ae/apex/myapp [R,L]


please advise how to resolve the issue


Those look like Apache HTTPD rewrite rules. How are they supported in 
Apache Tomcat?


-Terence Bandoian


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

Re: Fwd: [Community] try to add an community growth graph to the website

[Shuyang Wu]

Hi Mark,

Thanks for the guidance!

The problem is, I could not get the accurate commit date of each commit in
the changelog, especially for those that not bind with bugzilla. If I take
it right, the changelog would be the same or a subset of svn log, so I'm
not sure if there is anything new I could get from the changelog. One more
thing is that I go through the changelog for 5.5, 6.0, and 7.0 in 2012
(5.5.35-5.5.36, 6.0.36, and 7.0.25-7.0.35 separately), but failed to find
out new contributors. Could you help me find them?

Thanks for your time!

Best,
Shuyang

Mark Thomas  于2021年5月20日周四 上午4:16写道：

> On 19/05/2021 22:13, Shuyang Wu wrote:
> #
> 
>
> > michaelo, 2018-08-21 04:16:42 -0400 EDT
> > woonsan, 2019-01-08 00:01:45 -0500 EST
> >
> > I'm not familiar with svn at all :( so I'm not sure if I did it
> correctly.
> > Also, I failed to understand how to search with "provided by
> > ()". I'll appreciate it if you could give me some other
> > guidance and thanks again for your time!
>
> My point is that you'll get much better contributor data from the
> changelogs:
>
> http://tomcat.apache.org/tomcat-10.0-doc/changelog.html
> http://tomcat.apache.org/tomcat-9.0-doc/changelog.html
> http://tomcat.apache.org/tomcat-8.5-doc/changelog.html
> http://tomcat.apache.org/tomcat-8.0-doc/changelog.html
> http://tomcat.apache.org/tomcat-7.0-doc/changelog.html
> http://tomcat.apache.org/tomcat-6.0-doc/changelog.html
> http://tomcat.apache.org/tomcat-5.5-doc/changelog.html
>
> https://svn.apache.org/viewvc/tomcat/archive/tc5.0.x/trunk/container/webapps/docs/changelog.xml?view=co&revision=588818&content-type=text%2Fplain
>
> Before that gets tricker as the fixes don't contain IDs:
>
>
> https://svn.apache.org/viewvc/tomcat/archive/tc4.1.x/trunk/container/RELEASE-NOTES-4.1.txt?revision=788407&view=co
>
> Note that back-porting of fixes between versions means that the above
> with give a distorted picture of contributions per committer/contributor
> but it will give a more accurate view of contributor/committer count.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Fwd: [Community] try to add an community growth graph to the website

[Mark Thomas]

On 19/05/2021 22:13, Shuyang Wu wrote:
#



michaelo, 2018-08-21 04:16:42 -0400 EDT
woonsan, 2019-01-08 00:01:45 -0500 EST

I'm not familiar with svn at all :( so I'm not sure if I did it correctly.
Also, I failed to understand how to search with "provided by
()". I'll appreciate it if you could give me some other
guidance and thanks again for your time!


My point is that you'll get much better contributor data from the 
changelogs:


http://tomcat.apache.org/tomcat-10.0-doc/changelog.html
http://tomcat.apache.org/tomcat-9.0-doc/changelog.html
http://tomcat.apache.org/tomcat-8.5-doc/changelog.html
http://tomcat.apache.org/tomcat-8.0-doc/changelog.html
http://tomcat.apache.org/tomcat-7.0-doc/changelog.html
http://tomcat.apache.org/tomcat-6.0-doc/changelog.html
http://tomcat.apache.org/tomcat-5.5-doc/changelog.html
https://svn.apache.org/viewvc/tomcat/archive/tc5.0.x/trunk/container/webapps/docs/changelog.xml?view=co&revision=588818&content-type=text%2Fplain

Before that gets tricker as the fixes don't contain IDs:

https://svn.apache.org/viewvc/tomcat/archive/tc4.1.x/trunk/container/RELEASE-NOTES-4.1.txt?revision=788407&view=co

Note that back-porting of fixes between versions means that the above 
with give a distorted picture of contributions per committer/contributor 
but it will give a more accurate view of contributor/committer count.


Mark

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

Re: Fwd: Jersey libraries 1.18 worked with Tomcat 7 but failing with Tomcat 9 : Root resource classes not getting scanned

[Christopher Schultz]

Yogish,

On 1/29/21 01:24, Yogish Anand wrote:

We were using Tomcat 7 and the Jersey libraries 1.18 was able to scan the
packages with the below two lines

com.sun.jersey.api.core.PackagesResourceConfig.init Scanning for root
resource and provider classes in the packages:
 v1

com.sun.jersey.api.core.ScanningResourceConfig logClasses
 INFO: Root resource classes found:
 class v1.add

We migrated to Tomcat 9 (Note : We use the old server.xml which we used in
Tomcat 7)


You should probably stop right now and fix that. conf/server.xml files 
are not compatible between versions unless you are extraordinarily lucky.



we are getting only the below line but we don't get the message
"Root resource classes found" and the REST API is failing

com.sun.jersey.api.core.PackagesResourceConfig.init Scanning for root
resource and provider classes in the packages:
 v1

Please let me know how to troubleshoot and fix the issue?


I think you will get better feedback from the Jersey project than the 
Tomcat project. We have no idea what Jersey is doing when it scans for 
"root resource and provider classes".


-chris

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

Re: Fwd: Re: At least one JAR was scanned for TLDs yet contained no TLDs.

[Christopher Schultz]

Raivo,

On 10/8/20 07:22, Raivo Rebane wrote:
> Hello
> 
> if I start standalone tomcat program looks like:
> 
> 17868 ?    Sl 0:02 /usr/lib/jvm/default-java/bin/java
> -Djava.util.logging.config.file=/opt/tomcat/latest/conf/logging.properties
> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
> -Djava.security.egd=file:///dev/urandom -Djava.awt.headless=true
> -Djdk.tls.ephemeralDHKeySize=2048
> -Djava.protocol.handler.pkgs=org.apache.catalina.webresources
> -Dorg.apache.catalina.security.SecurityListener.UMASK=0027 -Xms512M
> -Xmx1024M -server -XX:+UseParallelGC -Dignore.endorsed.dirs= -classpath
> /opt/tomcat/latest/bin/bootstrap.jar:/opt/tomcat/latest/bin/tomcat-juli.jar
> -Dcatalina.base=/opt/tomcat/latest -Dcatalina.home=/opt/tomcat/latest
> -Djava.io.tmpdir=/opt/tomcat/latest/temp
> org.apache.catalina.startup.Bootstrap start
> 
> No jars is added to classpath

Please read the replies to this question you got two days ago. The
classpath does not matter.

-chris

> On 08.10.20 13:59, Raivo Rebane wrote:
> 
>>
>>
>>
>>  Forwarded Message 
>> Subject: Re: At least one JAR was scanned for TLDs yet contained
>> no TLDs.
>> Date: Thu, 8 Oct 2020 13:37:49 +0300
>> From: Raivo Rebane 
>> To: Martin Grigorov ,
>> users-get.123_...@tomcat.apache.org
>>
>>
>>
>> Hello
>>
>> I debaged the jars list and got following:
>>
>> 08-Oct-2020 13:27:07.240 FINE [main]
>> org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD
>> files were found in
>> [file:/opt/tomcat/apache-tomcat-9.0.38/lib/batik-parser.jar]. Consider
>> adding the JAR to the
>> tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in
>> CATALINA_BASE/conf/catalina.properties file.
>> 08-Oct-2020 13:27:07.241 FINE [main]
>> org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD
>> files were found in
>> [file:/opt/tomcat/apache-tomcat-9.0.38/lib/batik-transcoder.jar].
>> Consider adding the JAR to the
>> tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in
>> CATALINA_BASE/conf/catalina.properties file.
>> 08-Oct-2020 13:27:07.241 FINE [main]
>> org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD
>> files were found in
>> [file:/opt/tomcat/apache-tomcat-9.0.38/lib/batik-gui-util.jar].
>> Consider adding the JAR to the
>> tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in
>> CATALINA_BASE/conf/catalina.properties file.
>> 08-Oct-2020 13:27:07.241 FINE [main]
>> org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD
>> files were found in
>> [file:/opt/tomcat/apache-tomcat-9.0.38/lib/batik-svggen.jar]. Consider
>> adding the JAR to the
>> tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in
>> CATALINA_BASE/conf/catalina.properties file.
>> 08-Oct-2020 13:27:07.241 FINE [main]
>> org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD
>> files were found in
>> [file:/opt/tomcat/apache-tomcat-9.0.38/lib/batik-xml.jar]. Consider
>> adding the JAR to the
>> tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in
>> CATALINA_BASE/conf/catalina.properties file.
>> 08-Oct-2020 13:27:07.241 FINE [main]
>> org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD
>> files were found in
>> [file:/opt/tomcat/apache-tomcat-9.0.38/lib/batik-awt-util.jar].
>> Consider adding the JAR to the
>> tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in
>> CATALINA_BASE/conf/catalina.properties file.
>> 08-Oct-2020 13:27:07.242 FINE [main]
>> org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD
>> files were found in
>> [file:/opt/tomcat/apache-tomcat-9.0.38/lib/batik-util.jar]. Consider
>> adding the JAR to the
>> tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in
>> CATALINA_BASE/conf/catalina.properties file.
>> 08-Oct-2020 13:27:07.242 FINE [main]
>> org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD
>> files were found in
>> [file:/opt/tomcat/apache-tomcat-9.0.38/lib/batik-script.jar]. Consider
>> adding the JAR to the
>> tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in
>> CATALINA_BASE/conf/catalina.properties file.
>> 08-Oct-2020 13:27:07.242 FINE [main]
>> org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD
>> files were found in
>> [file:/opt/tomcat/apache-tomcat-9.0.38/lib/batik-bridge.jar]. Consider
>> adding the JAR to the
>> tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in
>> CATALINA_BASE/conf/catalina.properties file.
>> 08-Oct-2020 13:27:07.242 FINE [main]
>> org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD
>> files were found in
>> [file:/opt/tomcat/apache-tomcat-9.0.38/lib/batik-dom.jar]. Consider
>> adding the JAR to the
>> tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in
>> CATALINA_BASE/conf/catalina.properties file.
>> 08-Oct-2020 13:27:07.242 FINE [main]
>> org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD
>> files were found in
>> [file:/o

Re: Fwd: Re: At least one JAR was scanned for TLDs yet contained no TLDs.

[Martin Grigorov]

On Thu, Oct 8, 2020 at 3:31 PM Raivo Rebane  wrote:

> Hello
>
> if I start standalone tomcat program looks like:
>
> 17868 ?Sl 0:02 /usr/lib/jvm/default-java/bin/java
> -Djava.util.logging.config.file=/opt/tomcat/latest/conf/logging.properties
> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
> -Djava.security.egd=file:///dev/urandom -Djava.awt.headless=true
> -Djdk.tls.ephemeralDHKeySize=2048
> -Djava.protocol.handler.pkgs=org.apache.catalina.webresources
> -Dorg.apache.catalina.security.SecurityListener.UMASK=0027 -Xms512M
> -Xmx1024M -server -XX:+UseParallelGC -Dignore.endorsed.dirs= -classpath
> /opt/tomcat/latest/bin/bootstrap.jar:/opt/tomcat/latest/bin/tomcat-juli.jar
>
> -Dcatalina.base=/opt/tomcat/latest -Dcatalina.home=/opt/tomcat/latest
> -Djava.io.tmpdir=/opt/tomcat/latest/temp
> org.apache.catalina.startup.Bootstrap start
>
> No jars is added to classpath
>

What are you trying to do?
Why do you start it this way and what issue do you think you have with the
TLDs ?


>
> Raivo
>
> On 08.10.20 13:59, Raivo Rebane wrote:
>
> >
> >
> >
> >  Forwarded Message 
> > Subject: Re: At least one JAR was scanned for TLDs yet contained
> > no TLDs.
> > Date: Thu, 8 Oct 2020 13:37:49 +0300
> > From: Raivo Rebane 
> > To: Martin Grigorov ,
> > users-get.123_...@tomcat.apache.org
> >
> >
> >
> > Hello
> >
> > I debaged the jars list and got following:
> >
> > 08-Oct-2020 13:27:07.240 FINE [main]
> > org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD
> > files were found in
> > [file:/opt/tomcat/apache-tomcat-9.0.38/lib/batik-parser.jar]. Consider
> > adding the JAR to the
> > tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in
> > CATALINA_BASE/conf/catalina.properties file.
> > 08-Oct-2020 13:27:07.241 FINE [main]
> > org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD
> > files were found in
> > [file:/opt/tomcat/apache-tomcat-9.0.38/lib/batik-transcoder.jar].
> > Consider adding the JAR to the
> > tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in
> > CATALINA_BASE/conf/catalina.properties file.
> > 08-Oct-2020 13:27:07.241 FINE [main]
> > org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD
> > files were found in
> > [file:/opt/tomcat/apache-tomcat-9.0.38/lib/batik-gui-util.jar].
> > Consider adding the JAR to the
> > tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in
> > CATALINA_BASE/conf/catalina.properties file.
> > 08-Oct-2020 13:27:07.241 FINE [main]
> > org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD
> > files were found in
> > [file:/opt/tomcat/apache-tomcat-9.0.38/lib/batik-svggen.jar]. Consider
> > adding the JAR to the
> > tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in
> > CATALINA_BASE/conf/catalina.properties file.
> > 08-Oct-2020 13:27:07.241 FINE [main]
> > org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD
> > files were found in
> > [file:/opt/tomcat/apache-tomcat-9.0.38/lib/batik-xml.jar]. Consider
> > adding the JAR to the
> > tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in
> > CATALINA_BASE/conf/catalina.properties file.
> > 08-Oct-2020 13:27:07.241 FINE [main]
> > org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD
> > files were found in
> > [file:/opt/tomcat/apache-tomcat-9.0.38/lib/batik-awt-util.jar].
> > Consider adding the JAR to the
> > tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in
> > CATALINA_BASE/conf/catalina.properties file.
> > 08-Oct-2020 13:27:07.242 FINE [main]
> > org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD
> > files were found in
> > [file:/opt/tomcat/apache-tomcat-9.0.38/lib/batik-util.jar]. Consider
> > adding the JAR to the
> > tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in
> > CATALINA_BASE/conf/catalina.properties file.
> > 08-Oct-2020 13:27:07.242 FINE [main]
> > org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD
> > files were found in
> > [file:/opt/tomcat/apache-tomcat-9.0.38/lib/batik-script.jar]. Consider
> > adding the JAR to the
> > tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in
> > CATALINA_BASE/conf/catalina.properties file.
> > 08-Oct-2020 13:27:07.242 FINE [main]
> > org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD
> > files were found in
> > [file:/opt/tomcat/apache-tomcat-9.0.38/lib/batik-bridge.jar]. Consider
> > adding the JAR to the
> > tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in
> > CATALINA_BASE/conf/catalina.properties file.
> > 08-Oct-2020 13:27:07.242 FINE [main]
> > org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD
> > files were found in
> > [file:/opt/tomcat/apache-tomcat-9.0.38/lib/batik-dom.jar]. Consider
> > adding the JAR to the
> > tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in
> > CATALINA_BASE/conf/catalina.properties file.
> > 08-Oct-2020 13:27:07.242 FI

Re: Fwd: Re: At least one JAR was scanned for TLDs yet contained no TLDs.

[Raivo Rebane]

Hello

if I start standalone tomcat program looks like:

17868 ?    Sl 0:02 /usr/lib/jvm/default-java/bin/java 
-Djava.util.logging.config.file=/opt/tomcat/latest/conf/logging.properties 
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager 
-Djava.security.egd=file:///dev/urandom -Djava.awt.headless=true 
-Djdk.tls.ephemeralDHKeySize=2048 
-Djava.protocol.handler.pkgs=org.apache.catalina.webresources 
-Dorg.apache.catalina.security.SecurityListener.UMASK=0027 -Xms512M 
-Xmx1024M -server -XX:+UseParallelGC -Dignore.endorsed.dirs= -classpath 
/opt/tomcat/latest/bin/bootstrap.jar:/opt/tomcat/latest/bin/tomcat-juli.jar 
-Dcatalina.base=/opt/tomcat/latest -Dcatalina.home=/opt/tomcat/latest 
-Djava.io.tmpdir=/opt/tomcat/latest/temp 
org.apache.catalina.startup.Bootstrap start


No jars is added to classpath

Raivo

On 08.10.20 13:59, Raivo Rebane wrote:





 Forwarded Message 
Subject: Re: At least one JAR was scanned for TLDs yet contained 
no TLDs.

Date: Thu, 8 Oct 2020 13:37:49 +0300
From: Raivo Rebane 
To: Martin Grigorov , 
users-get.123_...@tomcat.apache.org




Hello

I debaged the jars list and got following:

08-Oct-2020 13:27:07.240 FINE [main] 
org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD 
files were found in 
[file:/opt/tomcat/apache-tomcat-9.0.38/lib/batik-parser.jar]. Consider 
adding the JAR to the 
tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in 
CATALINA_BASE/conf/catalina.properties file.
08-Oct-2020 13:27:07.241 FINE [main] 
org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD 
files were found in 
[file:/opt/tomcat/apache-tomcat-9.0.38/lib/batik-transcoder.jar]. 
Consider adding the JAR to the 
tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in 
CATALINA_BASE/conf/catalina.properties file.
08-Oct-2020 13:27:07.241 FINE [main] 
org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD 
files were found in 
[file:/opt/tomcat/apache-tomcat-9.0.38/lib/batik-gui-util.jar]. 
Consider adding the JAR to the 
tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in 
CATALINA_BASE/conf/catalina.properties file.
08-Oct-2020 13:27:07.241 FINE [main] 
org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD 
files were found in 
[file:/opt/tomcat/apache-tomcat-9.0.38/lib/batik-svggen.jar]. Consider 
adding the JAR to the 
tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in 
CATALINA_BASE/conf/catalina.properties file.
08-Oct-2020 13:27:07.241 FINE [main] 
org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD 
files were found in 
[file:/opt/tomcat/apache-tomcat-9.0.38/lib/batik-xml.jar]. Consider 
adding the JAR to the 
tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in 
CATALINA_BASE/conf/catalina.properties file.
08-Oct-2020 13:27:07.241 FINE [main] 
org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD 
files were found in 
[file:/opt/tomcat/apache-tomcat-9.0.38/lib/batik-awt-util.jar]. 
Consider adding the JAR to the 
tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in 
CATALINA_BASE/conf/catalina.properties file.
08-Oct-2020 13:27:07.242 FINE [main] 
org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD 
files were found in 
[file:/opt/tomcat/apache-tomcat-9.0.38/lib/batik-util.jar]. Consider 
adding the JAR to the 
tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in 
CATALINA_BASE/conf/catalina.properties file.
08-Oct-2020 13:27:07.242 FINE [main] 
org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD 
files were found in 
[file:/opt/tomcat/apache-tomcat-9.0.38/lib/batik-script.jar]. Consider 
adding the JAR to the 
tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in 
CATALINA_BASE/conf/catalina.properties file.
08-Oct-2020 13:27:07.242 FINE [main] 
org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD 
files were found in 
[file:/opt/tomcat/apache-tomcat-9.0.38/lib/batik-bridge.jar]. Consider 
adding the JAR to the 
tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in 
CATALINA_BASE/conf/catalina.properties file.
08-Oct-2020 13:27:07.242 FINE [main] 
org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD 
files were found in 
[file:/opt/tomcat/apache-tomcat-9.0.38/lib/batik-dom.jar]. Consider 
adding the JAR to the 
tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in 
CATALINA_BASE/conf/catalina.properties file.
08-Oct-2020 13:27:07.242 FINE [main] 
org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD 
files were found in 
[file:/opt/tomcat/apache-tomcat-9.0.38/lib/batik-gvt.jar]. Consider 
adding the JAR to the 
tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in 
CATALINA_BASE/conf/catalina.properties file.
08-Oct-2020 13:27:07.242 FINE [main] 
org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD 
files were found in 
[file:/opt/tomcat/apache-tomcat-9.0.38/lib/bat

Re: Fwd: Reverse proxy and SSL redirect

[rugman66 .]

On Wed, Jul 1, 2020 at 3:26 AM Mark Thomas  wrote:
>
> On 01/07/2020 00:41, rugman66 . wrote:
> > On Wed, Apr 22, 2020 at 9:21 AM Mark Thomas  wrote:
> >>
> >> On 22/04/2020 00:11, rugman66 . wrote:
> >>
> >> 
> >>
> >>>Tomcat log  (I'm trying to get more debug level logging)
> >>> 2020-04-21 13:39:33 INFO  app.CompletionRestController
> >>> Unsupported Media Type in Header
> >>>
> >>>   Postman
> >>>415 Unsupported Media Type
> >>>
> >>>   GET URL
> >>> http://server.com/app/api/completions.json?username=foo
> >>>
> >>> Both Tomcat and Apache are running SSL because all internal endpoints
> >>> are required to be secure.
> >>
> >> Looks like the app is generating the error. That moves us forwards.
> >>
> >> Try enabling the RequestDumperFilter. That should dump the full set of
> >> request headers received which will hopefully help explain what is
going on.
> >>
> >> Mark
> >
> > Hi Mark,
> >
> > Was on unplanned leave for the past few months, but back.
> >
> > I did try to enable RequestDumperFilter, however the file was created
> > but no log entries created. I did find something interesting. When I
> > test in Postman with
> > HTTP it does redirect to HTTPD but throws the error. However when I
> > change the URL in Postman using HTTPD I get the expected reply and see
> > the
> > proxy is indeed working. It's only throwing the error when the
> > redirect occurs. Seems to me the issue lies there, but I still can't
> > find a resolution. Any
> > suggestions would be appreciated.
>
> You need to find a way to see the full traffic for both client<->httpd
> and httpd<->Tomcat.
>
> Wireshark is one option. You'll need to configure it to decrypt the TLS.
>
> The access logs will also confirm whether requests are passed to Tomcat
> or handled by httpd.
>
> Mark

Unfortunately I cannot use wireshark as this is in one of our data centers,
and information security would flag packet sniffing as malicious. However I
did record the Apache access log entry for one attempt
and Apache error log entries from three separate attempts. Interestingly
enough all three differ in length. Also included the catalina.out log
entry. Below are the log snipents.

Appreciate your time
-John


*Tomcat*
catalina.out:
2020-07-01 13:18:59 INFO  app.CompletionRestController Unsupported Media
Type in Header

*Apache*
access log:
10.24.36.111 - - [01/Jul/2020:13:18:59 -0700] "GET
/app/api/completions.json?username=me HTTP/1.1" 415 46 "-" "Mozilla/5.0
(Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0"

error log:
[Wed Jul 01 10:42:24.994833 2020] [ssl:info] [pid 4874] [client
10.24.36.111:54100] AH01964: Connection to child 2 established (server
englearn-app3.foo.com:443)
[Wed Jul 01 10:42:25.011695 2020] [proxy:debug] [pid 72913]
proxy_util.c(1843): AH00925: initializing worker proxy:reverse shared
[Wed Jul 01 10:42:25.011740 2020] [proxy:debug] [pid 72913]
proxy_util.c(1885): AH00927: initializing worker proxy:reverse local
[Wed Jul 01 10:42:25.011903 2020] [proxy:debug] [pid 72913]
proxy_util.c(1936): AH00931: initialized single connection worker in child
72913 for (*)
[Wed Jul 01 10:42:25.011912 2020] [proxy:debug] [pid 72913]
proxy_util.c(1843): AH00925: initializing worker
https://englearn-app3.foo.com:8443/app shared
[Wed Jul 01 10:42:25.011917 2020] [proxy:debug] [pid 72913]
proxy_util.c(1885): AH00927: initializing worker
https://englearn-app3.foo.com:8443/app local
[Wed Jul 01 10:42:25.011934 2020] [proxy:debug] [pid 72913]
proxy_util.c(1936): AH00931: initialized single connection worker in child
72913 for (englearn-app3.foo.com)
[Wed Jul 01 10:42:25.041766 2020] [proxy:trace2] [pid 4874]
proxy_util.c(1985): [client 10.24.36.111:54100] https: found worker
https://englearn-app3.foo.com:8443/app for
https://englearn-app3.foo.com:8443/app/api/completions.json?username=me,
referer: http://englearn-app3.foo.com/app/api/completions.json?username=me
[Wed Jul 01 10:42:25.041787 2020] [proxy:debug] [pid 4874]
mod_proxy.c(1123): [client 10.24.36.111:54100] AH01143: Running scheme
https handler (attempt 0), referer:
http://englearn-app3.foo.com/app/api/completions.json?username=me
[Wed Jul 01 10:42:25.041804 2020] [proxy:debug] [pid 4874]
proxy_util.c(2203): AH00942: HTTPS: has acquired connection for (
englearn-app3.foo.com)
[Wed Jul 01 10:42:25.041826 2020] [proxy:debug] [pid 4874]
proxy_util.c(2256): [client 10.24.36.111:54100] AH00944: connecting
https://englearn-app3.foo.com:8443/app/api/completions.json?username=me to
englearn-app3.foo.com:8443, referer:
http://englearn-app3.foo.com/app/api/completions.json?username=me
[Wed Jul 01 10:42:25.042535 2020] [proxy:debug] [pid 4874]
proxy_util.c(2426): [client 10.24.36.111:54100] AH00947: connected
/app/api/completions.json?username=me to englearn-app3.foo.com:8443,
referer: http://englearn-app3.foo.com/app/api/completions.json?username=me
[Wed Jul 01 10:42:25.042561 2020] [proxy:trace2] [pid 4874]
proxy_util.c(2768): HTTPS:

Re: Fwd: Reverse proxy and SSL redirect

[Mark Thomas]

On 01/07/2020 00:41, rugman66 . wrote:
> On Wed, Apr 22, 2020 at 9:21 AM Mark Thomas  wrote:
>>
>> On 22/04/2020 00:11, rugman66 . wrote:
>>
>> 
>>
>>>Tomcat log  (I'm trying to get more debug level logging)
>>> 2020-04-21 13:39:33 INFO  app.CompletionRestController
>>> Unsupported Media Type in Header
>>>
>>>   Postman
>>>415 Unsupported Media Type
>>>
>>>   GET URL
>>> http://server.com/app/api/completions.json?username=foo
>>>
>>> Both Tomcat and Apache are running SSL because all internal endpoints
>>> are required to be secure.
>>
>> Looks like the app is generating the error. That moves us forwards.
>>
>> Try enabling the RequestDumperFilter. That should dump the full set of
>> request headers received which will hopefully help explain what is going on.
>>
>> Mark
> 
> Hi Mark,
> 
> Was on unplanned leave for the past few months, but back.
> 
> I did try to enable RequestDumperFilter, however the file was created
> but no log entries created. I did find something interesting. When I
> test in Postman with
> HTTP it does redirect to HTTPD but throws the error. However when I
> change the URL in Postman using HTTPD I get the expected reply and see
> the
> proxy is indeed working. It's only throwing the error when the
> redirect occurs. Seems to me the issue lies there, but I still can't
> find a resolution. Any
> suggestions would be appreciated.

You need to find a way to see the full traffic for both client<->httpd
and httpd<->Tomcat.

Wireshark is one option. You'll need to configure it to decrypt the TLS.

The access logs will also confirm whether requests are passed to Tomcat
or handled by httpd.

Mark

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

Re: Fwd: Reverse proxy and SSL redirect

[rugman66 .]

On Wed, Apr 22, 2020 at 9:21 AM Mark Thomas  wrote:
>
> On 22/04/2020 00:11, rugman66 . wrote:
>
> 
>
> >Tomcat log  (I'm trying to get more debug level logging)
> > 2020-04-21 13:39:33 INFO  app.CompletionRestController
> > Unsupported Media Type in Header
> >
> >   Postman
> >415 Unsupported Media Type
> >
> >   GET URL
> > http://server.com/app/api/completions.json?username=foo
> >
> > Both Tomcat and Apache are running SSL because all internal endpoints
> > are required to be secure.
>
> Looks like the app is generating the error. That moves us forwards.
>
> Try enabling the RequestDumperFilter. That should dump the full set of
> request headers received which will hopefully help explain what is going on.
>
> Mark

Hi Mark,

Was on unplanned leave for the past few months, but back.

I did try to enable RequestDumperFilter, however the file was created
but no log entries created. I did find something interesting. When I
test in Postman with
HTTP it does redirect to HTTPD but throws the error. However when I
change the URL in Postman using HTTPD I get the expected reply and see
the
proxy is indeed working. It's only throwing the error when the
redirect occurs. Seems to me the issue lies there, but I still can't
find a resolution. Any
suggestions would be appreciated.

Regards
-John

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

Re: Fwd: Reverse proxy and SSL redirect

[Mark Thomas]

On 22/04/2020 00:11, rugman66 . wrote:



>Tomcat log  (I'm trying to get more debug level logging)
> 2020-04-21 13:39:33 INFO  app.CompletionRestController
> Unsupported Media Type in Header
> 
>   Postman
>415 Unsupported Media Type
> 
>   GET URL
> http://server.com/app/api/completions.json?username=foo
> 
> Both Tomcat and Apache are running SSL because all internal endpoints
> are required to be secure.

Looks like the app is generating the error. That moves us forwards.

Try enabling the RequestDumperFilter. That should dump the full set of
request headers received which will hopefully help explain what is going on.

Mark

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

Re: Fwd: Reverse proxy and SSL redirect

[rugman66 .]

On Sat, Apr 18, 2020 at 1:46 AM Mark Thomas  wrote:
>
> On 17/04/2020 18:15, rugman66 . wrote:
> > Made correction to ProxyPass and ProxyPassReverse.
>
> Good. Changing the context path in the reverse proxy opens up the
> possibility for all sorts of breakage and is generally best avoided if
> at all possible.
>
> 
>
> > I have Apache 2.4.6 running as reverse proxy for Tomcat  7.0.96, both
> > running SSL, and a functioning redirect from HTTP to HTTPS for both
> > Apache and Tomcat.  ( Need to use both these releases due to IT
> > availability and app requirements )
> > Prior to enabling SSL on both a Json GET command made to the
> > application worked. Now after enabling SSL and the Apache redirect,
> > when the json calls are made to the application with the URL starting
> > with HTTP:// that should be
> > redirected to HTTPS:// the following errors occurs.
> >
> > 415 Unsupported media type
> > "message": "Unsupported Media Type in Header"
>
> Can you tell where that error message is coming from? httpd? Tomcat? The
> application?
>
> > When the same json GET command is issued to the same URL using
> > HTTPS:// it works. It looks as if communication is breaking down
> > between Apache and Tomcat.
>
> What URL is used with that GET?
>
> What appears in the access logs (httpd and Tomcat) for each of those?
>
> Can you also log the HTTP headers sent and received by the client for
> each request?
>
> > Apache
>
> I'm no httpd expert...
>
> > 
> >ServerName http://foo.domain.com
> >Redirect / https://foo.domain.com/
> > 
>
> But the above looks to be consistent with:
> https://cwiki.apache.org/confluence/display/HTTPD/RedirectSSL
>
> > 
> > SSLEngine on
> > SSLProxyProtocol all
> > SSLCertificateFile "/auto/foo/ssl_certificate/cert.cer"
> > SSLCertificateChainFile "/auto/some-path/ssl_certificate/chain.cer"
> > SSLCertificateKeyFile "/auto/some-path/ssl_certificate/some.key"
> > SSLCipherSuite "ALL:!ADH:!SSLv2:!EXPORT40:!EXP:!LOW"
> > ServerName "foo.domain.com"
> > TraceEnable Off
> > ProxyRequests Off
> > ProxyPreserveHost Off
> > SSLProxyEngine on
> > AddDefaultCharset utf-8
> > AddType 'application/json; charset=UTF-8' .json
> > ProxyPass   "/app" "https://foo.domain.com:8443/app";
> > ProxyPassReverse"/app" "https://foo.domain.com:8443/app";
> > 
>
> Hmm. I'm wondering about that AddType but it looks OK.
>
> > Tomcat
> >
> >  >connectionTimeout="2"
> >redirectPort="443"
> >proxyName="foo.domian.com"
> >ProxyPort="80"
>
> Will this become unnecessary once the HTTPS redirect is working? The
> redirect will always happen in httpd.
>
> >  >  port="8443"
> >  scheme="https"
> >  secure="true"
> >  protocol="org.apache.coyote.http11.Http11AprProtocol"
> >  SSLEnabled="true"
> >  SSLCipherSuite="ALL:!ADH:!SSLv2:!EXPORT40:!EXP:!LOW"
> >  SSLCertificateFile="/auto/foo/ssl_certificate/cert.cer"
> >  SSLCertificateChainFile="/auto/some-path/ssl_certificate/chain.cer"
> >  SSLCertificateKeyFile="/auto/some-path/ssl_certificate/some.key"
> >  maxThreads="150"
> >  clientAuth="false"
> >  SSLProtocol="TLSv1.2 -SSLv2 -SSLv3 -TLSv1 -TLSv1.1"
> >  maxHttpHeaderSize="32768"
> >  URIEncoding="UTF-8"
> > />
>
> Again, looks to be OK.
>
> > Appreciate any insight.
>
> I'd want to look at exactly what was in each request/response at each
> stage of this.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

Hi Mark,
Answers inline below.


Can you tell where that error message is coming from? httpd? Tomcat?
The  application?

 HTTPD log
  [Tue Apr 21 13:39:33.741636 2020] [ssl:info] [pid 38749]
[client 10.24.61.248:52733] AH01964: Connection to child 0 established
(server foo:443)
[Tue Apr 21 13:39:33.781069 2020] [proxy:trace2] [pid 38749]
proxy_util.c(1985): [client 10.24.61.248:52733] https: found worker
https://foo:8443/foo for
https://foo:8443/foo/api/completions.json?username=foo, referer:
http://foo/app/api/completions.json?username=foo
[Tue Apr 21 13:39:33.781119 2020] [proxy:debug] [pid 38749]
mod_proxy.c(1123): [client 10.24.61.248:52733] AH01143: Running scheme
https handler (attempt 0), referer:
http://foo/app/api/completions.json?username=foo
[Tue Apr 21 13:39:33.781150 2020] [proxy:debug] [pid 38749]
proxy_util.c(2203): AH00942: HTTPS: has acquired connection for
(foo.com)
[Tue Apr 21 13:39:33.781476 2020] [proxy:debug] [pid 38749]
proxy_util.c(2256): [client 10.24.61.248:52733] AH00944: connecting
https://foo:8443/app/api/completions.json?username=foo to foo:8443,
referer: http://foo/app/api/completions.json?username=foo
[Tue Apr 21 13:39:33.781553 2020] [proxy:debug] [pid 38749]
proxy_util.c(2426): [client 10.24.61.248:

Re: Fwd: Reverse proxy and SSL redirect

[Mark Thomas]

On 17/04/2020 18:15, rugman66 . wrote:
> Made correction to ProxyPass and ProxyPassReverse.

Good. Changing the context path in the reverse proxy opens up the
possibility for all sorts of breakage and is generally best avoided if
at all possible.



> I have Apache 2.4.6 running as reverse proxy for Tomcat  7.0.96, both
> running SSL, and a functioning redirect from HTTP to HTTPS for both
> Apache and Tomcat.  ( Need to use both these releases due to IT
> availability and app requirements )
> Prior to enabling SSL on both a Json GET command made to the
> application worked. Now after enabling SSL and the Apache redirect,
> when the json calls are made to the application with the URL starting
> with HTTP:// that should be
> redirected to HTTPS:// the following errors occurs.
> 
> 415 Unsupported media type
> "message": "Unsupported Media Type in Header"

Can you tell where that error message is coming from? httpd? Tomcat? The
application?

> When the same json GET command is issued to the same URL using
> HTTPS:// it works. It looks as if communication is breaking down
> between Apache and Tomcat.

What URL is used with that GET?

What appears in the access logs (httpd and Tomcat) for each of those?

Can you also log the HTTP headers sent and received by the client for
each request?

> Apache

I'm no httpd expert...

> 
>ServerName http://foo.domain.com
>Redirect / https://foo.domain.com/
> 

But the above looks to be consistent with:
https://cwiki.apache.org/confluence/display/HTTPD/RedirectSSL

> 
> SSLEngine on
> SSLProxyProtocol all
> SSLCertificateFile "/auto/foo/ssl_certificate/cert.cer"
> SSLCertificateChainFile "/auto/some-path/ssl_certificate/chain.cer"
> SSLCertificateKeyFile "/auto/some-path/ssl_certificate/some.key"
> SSLCipherSuite "ALL:!ADH:!SSLv2:!EXPORT40:!EXP:!LOW"
> ServerName "foo.domain.com"
> TraceEnable Off
> ProxyRequests Off
> ProxyPreserveHost Off
> SSLProxyEngine on
> AddDefaultCharset utf-8
> AddType 'application/json; charset=UTF-8' .json
> ProxyPass   "/app" "https://foo.domain.com:8443/app";
> ProxyPassReverse"/app" "https://foo.domain.com:8443/app";
> 

Hmm. I'm wondering about that AddType but it looks OK.

> Tomcat
> 
> connectionTimeout="2"
>redirectPort="443"
>proxyName="foo.domian.com"
>ProxyPort="80"

Will this become unnecessary once the HTTPS redirect is working? The
redirect will always happen in httpd.

>   port="8443"
>  scheme="https"
>  secure="true"
>  protocol="org.apache.coyote.http11.Http11AprProtocol"
>  SSLEnabled="true"
>  SSLCipherSuite="ALL:!ADH:!SSLv2:!EXPORT40:!EXP:!LOW"
>  SSLCertificateFile="/auto/foo/ssl_certificate/cert.cer"
>  SSLCertificateChainFile="/auto/some-path/ssl_certificate/chain.cer"
>  SSLCertificateKeyFile="/auto/some-path/ssl_certificate/some.key"
>  maxThreads="150"
>  clientAuth="false"
>  SSLProtocol="TLSv1.2 -SSLv2 -SSLv3 -TLSv1 -TLSv1.1"
>  maxHttpHeaderSize="32768"
>  URIEncoding="UTF-8"
> />

Again, looks to be OK.

> Appreciate any insight.

I'd want to look at exactly what was in each request/response at each
stage of this.

Mark

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

Re: Fwd: Tomcat 9.0.31 - BUG

[Mark Thomas]

On 03/04/2020 19:04, sathis kumar wrote:
> *Tomcat Users List >, *
> *"Thans for your reply.. When i tried with simple JSP", "worked. Fine..
> When i tried deploying my other application", "ran into that issue :("*

That points to an application problem, not a Tomcat problem.

You need to remove things from the application until you have the
simplest possible test case that reproduces the problem. And I expect
that, along the way, you'll find that you are packaging a different
(buggy) version of the EL API in your application - and that is what is
causing the problem.

Mark


> 
> 
> 
> javax.servlet.ServletException: javax.el.ELException: Unable to find
> ExpressionFactory of type: # Licensed to the Apache Software
> Foundation (ASF) under one or more
>   org.apache.jsp.index_jsp._jspService(index_jsp.java:428)
>   org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
>   javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
>   
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:477)
>   org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:385)
>   org.apache.jasper.servlet.JspServlet.service(JspServlet.java:329)
>   javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
>   org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
> 
> *ype* Exception Report
> *Message* javax.servlet.ServletException: javax.el.ELException: Unable to
> find ExpressionFactory of type: # Licensed to the Apache Software
> Foundation (ASF) under one or more
> *Description* The server encountered an unexpected condition that prevented
> it from fulfilling the request.
> *Exception*
> 
> org.apache.jasper.JasperException: javax.servlet.ServletException:
> javax.el.ELException: Unable to find ExpressionFactory of type: #
> Licensed to the Apache Software Foundation (ASF) under one or more
>   
> org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:639)
>   
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:500)
>   org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:385)
>   org.apache.jasper.servlet.JspServlet.service(JspServlet.java:329)
>   javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
>   org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
> 
> 
> On Fri, Apr 3, 2020 at 11:44 AM Mark Thomas  wrote:
> 
>> On 03/04/2020 16:33, sathis kumar wrote:
>>> Thanks much for your response. I am using the el-api.jar coming along
>> with
>>> Tomcat9.0.31/lib - Still a sample problem..
>>> JDK version we are using is - > 1.8
>>
>>
>> Please provide the simplest possible set of steps to recreate this error
>> from a clean Apache Tomcat 9.0.31 install.
>>
>> It should be possible to do this by adding a single JSP to a clean
>> install. Please provide us with that JSP.
>>
>> Mark
>>
>>
>>>
>>>
>>> On Fri, Apr 3, 2020 at 11:16 AM Christopher Schultz <
>>> ch...@christopherschultz.net> wrote:
>>>
>>> Sathis,
>>>
>>> You have run across this known bug:
>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=64097
>>>
>>> Please read that bug report for more details, particularly comment #8.
>>>
>>> Hope that helps,
>>> -chris
>>>
>>> On 4/3/20 11:05, sathis kumar wrote:
>> -- Forwarded message - From: sathis kumar
>>  Date: Fri, Apr 3, 2020 at 9:38 AM Subject:
>> Tomcat 9.0.31 - BUG To: 
>>
>>
>> My Application is working fine in prev version of all tomcat,
>> Planning to upgrade to 9.0.31 . I am running into the following
>> issue.. Pls help
>>
>> org.apache.jasper.JasperException:
>> org.apache.jasper.JasperException: Unable to compile class for JSP
>> at
>> org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServ
>>> letWrapper.java:605)
>>
>>
>>> at
>> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.
>>> java:423)
>>
>>
>>> Caused by: javax.el.ELException: Unable to find ExpressionFactory of typ
>>> e:
>> # Licensed to the Apache Software Foundation (ASF) under one or
>> more at
>> javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:152)
>> at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:9
>> any idea on this .. in older version 9.0.19 applications are
>> working fine
>>
>>
>>

 -
 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.

Re: Fwd: Tomcat 9.0.31 - BUG

[sathis kumar]

*Tomcat Users List >, *
*"Thans for your reply.. When i tried with simple JSP", "worked. Fine..
When i tried deploying my other application", "ran into that issue :("*



javax.servlet.ServletException: javax.el.ELException: Unable to find
ExpressionFactory of type: # Licensed to the Apache Software
Foundation (ASF) under one or more
org.apache.jsp.index_jsp._jspService(index_jsp.java:428)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
javax.servlet.http.HttpServlet.service(HttpServlet.java:741)

org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:477)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:385)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:329)
javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)

*ype* Exception Report
*Message* javax.servlet.ServletException: javax.el.ELException: Unable to
find ExpressionFactory of type: # Licensed to the Apache Software
Foundation (ASF) under one or more
*Description* The server encountered an unexpected condition that prevented
it from fulfilling the request.
*Exception*

org.apache.jasper.JasperException: javax.servlet.ServletException:
javax.el.ELException: Unable to find ExpressionFactory of type: #
Licensed to the Apache Software Foundation (ASF) under one or more

org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:639)

org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:500)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:385)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:329)
javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)


On Fri, Apr 3, 2020 at 11:44 AM Mark Thomas  wrote:

> On 03/04/2020 16:33, sathis kumar wrote:
> > Thanks much for your response. I am using the el-api.jar coming along
> with
> > Tomcat9.0.31/lib - Still a sample problem..
> > JDK version we are using is - > 1.8
>
>
> Please provide the simplest possible set of steps to recreate this error
> from a clean Apache Tomcat 9.0.31 install.
>
> It should be possible to do this by adding a single JSP to a clean
> install. Please provide us with that JSP.
>
> Mark
>
>
> >
> >
> > On Fri, Apr 3, 2020 at 11:16 AM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > Sathis,
> >
> > You have run across this known bug:
> > https://bz.apache.org/bugzilla/show_bug.cgi?id=64097
> >
> > Please read that bug report for more details, particularly comment #8.
> >
> > Hope that helps,
> > -chris
> >
> > On 4/3/20 11:05, sathis kumar wrote:
>  -- Forwarded message - From: sathis kumar
>   Date: Fri, Apr 3, 2020 at 9:38 AM Subject:
>  Tomcat 9.0.31 - BUG To: 
> 
> 
>  My Application is working fine in prev version of all tomcat,
>  Planning to upgrade to 9.0.31 . I am running into the following
>  issue.. Pls help
> 
>  org.apache.jasper.JasperException:
>  org.apache.jasper.JasperException: Unable to compile class for JSP
>  at
>  org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServ
> > letWrapper.java:605)
> 
> 
> > at
>  org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.
> > java:423)
> 
> 
> > Caused by: javax.el.ELException: Unable to find ExpressionFactory of typ
> > e:
>  # Licensed to the Apache Software Foundation (ASF) under one or
>  more at
>  javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:152)
>  at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:9
>  any idea on this .. in older version 9.0.19 applications are
>  working fine
> 
> 
> 
> >>
> >> -
> >> 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
>
>

-- 
Cheers,
Sathis Kumar

Re: Fwd: Tomcat 9.0.31 - BUG

[Mark Thomas]

On 03/04/2020 16:33, sathis kumar wrote:
> Thanks much for your response. I am using the el-api.jar coming along with
> Tomcat9.0.31/lib - Still a sample problem..
> JDK version we are using is - > 1.8


Please provide the simplest possible set of steps to recreate this error
from a clean Apache Tomcat 9.0.31 install.

It should be possible to do this by adding a single JSP to a clean
install. Please provide us with that JSP.

Mark


>
>
> On Fri, Apr 3, 2020 at 11:16 AM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
> Sathis,
> 
> You have run across this known bug:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=64097
> 
> Please read that bug report for more details, particularly comment #8.
> 
> Hope that helps,
> -chris
> 
> On 4/3/20 11:05, sathis kumar wrote:
 -- Forwarded message - From: sathis kumar
  Date: Fri, Apr 3, 2020 at 9:38 AM Subject:
 Tomcat 9.0.31 - BUG To: 


 My Application is working fine in prev version of all tomcat,
 Planning to upgrade to 9.0.31 . I am running into the following
 issue.. Pls help

 org.apache.jasper.JasperException:
 org.apache.jasper.JasperException: Unable to compile class for JSP
 at
 org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServ
> letWrapper.java:605)


> at
 org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.
> java:423)


> Caused by: javax.el.ELException: Unable to find ExpressionFactory of typ
> e:
 # Licensed to the Apache Software Foundation (ASF) under one or
 more at
 javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:152)
 at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:9
 any idea on this .. in older version 9.0.19 applications are
 working fine



>>
>> -
>> 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: Fwd: Tomcat 9.0.31 - BUG

[sathis kumar]

Thanks much for your response. I am using the el-api.jar coming along with
Tomcat9.0.31/lib - Still a sample problem..
JDK version we are using is - > 1.8


On Fri, Apr 3, 2020 at 11:16 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Sathis,
>
> You have run across this known bug:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=64097
>
> Please read that bug report for more details, particularly comment #8.
>
> Hope that helps,
> - -chris
>
> On 4/3/20 11:05, sathis kumar wrote:
> > -- Forwarded message - From: sathis kumar
> >  Date: Fri, Apr 3, 2020 at 9:38 AM Subject:
> > Tomcat 9.0.31 - BUG To: 
> >
> >
> > My Application is working fine in prev version of all tomcat,
> > Planning to upgrade to 9.0.31 . I am running into the following
> > issue.. Pls help
> >
> > org.apache.jasper.JasperException:
> > org.apache.jasper.JasperException: Unable to compile class for JSP
> > at
> > org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServ
> letWrapper.java:605)
> >
> >
> at
> > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.
> java:423)
> >
> >
> Caused by: javax.el.ELException: Unable to find ExpressionFactory of typ
> e:
> > # Licensed to the Apache Software Foundation (ASF) under one or
> > more at
> > javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:152)
> > at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:9
> > any idea on this .. in older version 9.0.19 applications are
> > working fine
> >
> >
> >
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6HUzgACgkQHPApP6U8
> pFiKcRAAxKaby2xj6kibPXp4hc2j9s0bF09e89wLKDtn7/q0Vr45M7pFKLikl041
> sjvM1sNw+YmycRDmoNp8iUTG9BMZ5n2HZI/MpCwr8z13MSmAMuitY8eaJ9sF5WjI
> Lus/G/FU7oC5r3ln6+tlKFolpAlyg/dTdM5JHEwXnM+0AD4pljMXLvFzzsOVdA5b
> n0a7+VDBmkz1KfubofXOnCXkie58WQ/c9z4CKTo6peZGCYlItEXJ8NVF1WQxKFg3
> dDThrJJvMtthzzgau0WJJ5PUhEXgLuarpavPZIxZ6vRHcZGLzq7Ed15Xz+WEtOPS
> 2hmkX987SvKGPWqTcwsKvcNsIfiGC99EP+svSlTvDOe/qa+FHdZEKyWW+5M6HBHz
> 1jWqaaUWHClHZ/AkbDIRAC4RoShQmOL7g2XOXgMVNkj0vAq24T+66u/HHj+/6vXf
> KBSXU0SuiMM8zLoTdB3YKOgNj2sML4xtyKvjOyksThrMdzJ5rTXOC4YcIFQI6jlg
> lYMAzc+dWDdjBSXIlFqqiiNAXTlrfLCBRZKUMLYa5XVtfbyv7hz4l2LCoPmo2nDf
> baZDg7rhvhJTV9ytk+GikU186F4jpAYiY2Osduh327WsooR9W/0Gw76iOL17/IDH
> a63/Itv/JN65hwJWeKEas8wBVmvK2UM8ua/bjnuf8AD63fQ1Grc=
> =NX9x
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-- 
Cheers,
Sathis Kumar

Re: Fwd: Tomcat 9.0.31 - BUG

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Sathis,

You have run across this known bug:
https://bz.apache.org/bugzilla/show_bug.cgi?id=64097

Please read that bug report for more details, particularly comment #8.

Hope that helps,
- -chris

On 4/3/20 11:05, sathis kumar wrote:
> -- Forwarded message - From: sathis kumar
>  Date: Fri, Apr 3, 2020 at 9:38 AM Subject:
> Tomcat 9.0.31 - BUG To: 
>
>
> My Application is working fine in prev version of all tomcat,
> Planning to upgrade to 9.0.31 . I am running into the following
> issue.. Pls help
>
> org.apache.jasper.JasperException:
> org.apache.jasper.JasperException: Unable to compile class for JSP
> at
> org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServ
letWrapper.java:605)
>
>
at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.
java:423)
>
>
Caused by: javax.el.ELException: Unable to find ExpressionFactory of typ
e:
> # Licensed to the Apache Software Foundation (ASF) under one or
> more at
> javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:152)
> at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:9
> any idea on this .. in older version 9.0.19 applications are
> working fine
>
>
>
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6HUzgACgkQHPApP6U8
pFiKcRAAxKaby2xj6kibPXp4hc2j9s0bF09e89wLKDtn7/q0Vr45M7pFKLikl041
sjvM1sNw+YmycRDmoNp8iUTG9BMZ5n2HZI/MpCwr8z13MSmAMuitY8eaJ9sF5WjI
Lus/G/FU7oC5r3ln6+tlKFolpAlyg/dTdM5JHEwXnM+0AD4pljMXLvFzzsOVdA5b
n0a7+VDBmkz1KfubofXOnCXkie58WQ/c9z4CKTo6peZGCYlItEXJ8NVF1WQxKFg3
dDThrJJvMtthzzgau0WJJ5PUhEXgLuarpavPZIxZ6vRHcZGLzq7Ed15Xz+WEtOPS
2hmkX987SvKGPWqTcwsKvcNsIfiGC99EP+svSlTvDOe/qa+FHdZEKyWW+5M6HBHz
1jWqaaUWHClHZ/AkbDIRAC4RoShQmOL7g2XOXgMVNkj0vAq24T+66u/HHj+/6vXf
KBSXU0SuiMM8zLoTdB3YKOgNj2sML4xtyKvjOyksThrMdzJ5rTXOC4YcIFQI6jlg
lYMAzc+dWDdjBSXIlFqqiiNAXTlrfLCBRZKUMLYa5XVtfbyv7hz4l2LCoPmo2nDf
baZDg7rhvhJTV9ytk+GikU186F4jpAYiY2Osduh327WsooR9W/0Gw76iOL17/IDH
a63/Itv/JN65hwJWeKEas8wBVmvK2UM8ua/bjnuf8AD63fQ1Grc=
=NX9x
-END PGP SIGNATURE-

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

Re: Fwd: Advice please for Tomcat 8.5.53-dev with log4j2

[Brian Burch]

On 18/3/20 5:54 pm, Luis Rodríguez Fernández wrote:

Grande Brian, congrats!

Sorry, I've just read your message, a bit late to the party: time ago I had
cooked a tomcat9 container + log4j2 with a sample spring-boot app deployed.
You can have a look here [1]


Thanks very much, Luis. Although just too late to help me, I was pleased 
to discover it confirmed Mark's advice and my own experience.


I guess I missed it from my own searches because I was focussed on the 
major logging transition between tomcat 7 and the early tomcat 8 
version, but your post was prominently identified with tomcat 9.


I have a busy weekend with non-self-isolating(!) family and friends, but 
I have a strong intention to draft an update to the tc8 wiki next week 
to match the current facts. Probably it will prove trivial for someone 
to port my change to the tc9 pages.


Thanks again for your thoughts,

Brian


Cheers,

Luis

[1]
https://db-blog.web.cern.ch/blog/luis-rodriguez-fernandez/2019-03-keeping-your-logs-clean-apache-tomcat-9-log4j2-and-spring-boot

El mié., 18 mar. 2020 a las 8:44, Brian Burch ()
escribió:


On 18/3/20 5:18 pm, Brian Burch wrote:




Could resist tinkering a bit more, but I'll be in trouble because I'm
late for dinner!!

Success! I have just created the catalina.log file formatted according
to my own log4j2.xml.

Yes, it was my stupid mistake, but I'll write tomorrow about what it did
to make it work.

Thanks for listening and advising. It really helped a lot and I wouldn't
have cracked it on my own.

Brian

-
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: Fwd: Advice please for Tomcat 8.5.53-dev with log4j2

[Luis Rodríguez Fernández]

Grande Brian, congrats!

Sorry, I've just read your message, a bit late to the party: time ago I had
cooked a tomcat9 container + log4j2 with a sample spring-boot app deployed.
You can have a look here [1]

Cheers,

Luis

[1]
https://db-blog.web.cern.ch/blog/luis-rodriguez-fernandez/2019-03-keeping-your-logs-clean-apache-tomcat-9-log4j2-and-spring-boot

El mié., 18 mar. 2020 a las 8:44, Brian Burch ()
escribió:

> On 18/3/20 5:18 pm, Brian Burch wrote:
> > 
>
> Could resist tinkering a bit more, but I'll be in trouble because I'm
> late for dinner!!
>
> Success! I have just created the catalina.log file formatted according
> to my own log4j2.xml.
>
> Yes, it was my stupid mistake, but I'll write tomorrow about what it did
> to make it work.
>
> Thanks for listening and advising. It really helped a lot and I wouldn't
> have cracked it on my own.
>
> Brian
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-- 

"Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better."

- Samuel Beckett

Re: Fwd: Advice please for Tomcat 8.5.53-dev with log4j2

[Brian Burch]

On 18/3/20 5:18 pm, Brian Burch wrote:




Could resist tinkering a bit more, but I'll be in trouble because I'm 
late for dinner!!


Success! I have just created the catalina.log file formatted according 
to my own log4j2.xml.


Yes, it was my stupid mistake, but I'll write tomorrow about what it did 
to make it work.


Thanks for listening and advising. It really helped a lot and I wouldn't 
have cracked it on my own.


Brian

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

Re: Fwd: Advice please for Tomcat 8.5.53-dev with log4j2

[Brian Burch]

On 18/3/20 2:57 pm, Brian Burch wrote:




I have done quite a lot of experiments, but I will stick to the case 
which appears to have produced the most encouraging(!) results.


I stumbled across 
https://logging.apache.org/log4j/2.x/log4j-appserver/index.html.


This short page has significant overlap with your suggestions, but there 
are differences too. I'll compare both before I say much more.


Your setenv puts log4j-api-2.13.1.jar on the classpath, but this file 
does not exist in my log4j2 binary download.


Following their advice, I first tried replacing it with 
log4j-appserver-2.13.1.jar, but startup failed with ClassNotFoundException.


Then I added (not replaced) log4j-1.2-api-2.13.1.jar, which seemed to be 
a good guess. That failed as follows:


Exception in thread "main" java.lang.ExceptionInInitializerError
Caused by: org.apache.juli.logging.LogConfigurationException: 
java.lang.reflect.InvocationTargetException
at 
org.apache.juli.logging.LogFactory.getInstance(LogFactory.java:136)
at 
org.apache.juli.logging.LogFactory.getInstance(LogFactory.java:153)

at org.apache.juli.logging.LogFactory.getLog(LogFactory.java:208)
at 
org.apache.catalina.startup.Bootstrap.(Bootstrap.java:51)

Caused by: java.lang.reflect.InvocationTargetException
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)

at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at 
org.apache.juli.logging.LogFactory.getInstance(LogFactory.java:134)

... 3 more
Caused by: java.lang.NoClassDefFoundError: 
org/apache/logging/log4j/LogManager

at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:756)
at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)

at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
at 
org.apache.logging.log4j.appserver.tomcat.TomcatLogger.(TomcatLogger.java:67)

... 8 more

However, I suspected my "current best effort" had disabled the internal 
tomcat logging (juli) but failed to enable log4j2. The message I quoted 
from catalina.out looked suspiciously like it had been handled by the 
jvm Logger, which is consistent with your suggestion

> I tried building log4j2 from source and gave up. It is a bit of a
nuisance that my development system uses both OpenJDK 8 and 11 because I 
keep forgetting which is required by my different projects. The log4j2 
toolchains requirement for java 9 was just too much to contemplate!


Clearly, adding log4j-1.2-api-2.13.1.jar did something significant, but 
I guess the jar is incompatible in some manner?


I recall the log4j2 pom.xml has a java.target of 1.7, as well as its 
toolchain requirement for java 9. I'm doing my very best to build and 
run tomcat under java 8. Is this relevant, or just a red herring?


I downloaded the apache-log4j-2.13.1 binaries, so I will deploy those 
jars in my tests.


I needed to make some minor tweaks to your setenv.bat before I had a 
syntax-free setenv.sh. Of course, I also replaced your ${CATALINA_BASE} 
with ${CATALINA_HOME} because that's where I'm currently putting the 
logging jars.


That bootstrap directory also has a copy of tomcat-juli from my java 8 
build from 5.8.53-dev source:-


-rw-r--r-- 1 tomcat8 tomcat8   51224 Mar  9 17:24 tomcat-juli.jar

I also noted from the web advice above that log4j2 looks for it's 
configuration file under the name log4j2-tomcat.xml, not log4j2.xml. I'm 
not keen on the advice to deploy the jars to new tomcat directories 
called catalina.home/log4j2/lib and ./log4j2/conf, so I favour your 
suggestion of using catalina.home/bin for my first tests.


Oh yes...

It didn't make any difference whether I called my configuration file 
conf/log4j2.xml or conf/log4j2-tomcat.xml.


I don't think it should matter that the default conf/logging.properties 
does not exist... wdyt?


I really appreciate your thoughtful advice. It would be useful for me to 
pare the advice down to its essentials and then update the tomcat 8 wiki 
advice.


So, to summarise, I've eliminated a lot of possible solutions and 
changed the failure symptoms

Re: Fwd: websocket connections consume too much memory

[Maxim Solodovnik]

Hello All,

Maybe this behavior is caused by the fact defaultMaxSessionIdleTimeout
is not set for websockets?

Can be updated as follows

final WsServerContainer sc =
(WsServerContainer)getServletContext().getAttribute(SERVER_CONTAINER_SERVLET_CONTEXT_ATTRIBUTE);
if (sc != null) {
 sc.setDefaultMaxSessionIdleTimeout(60 * 1000L);
}

On Mon, 25 Feb 2019 at 22:04, Иналь Кятов  wrote:
>
> I retest with
>
>
> *8.5.38*
>
> ...
>
> 
> org.apache.tomcat.embed
> tomcat-embed-websocket
> ${tomcat-embedded.version}
> 
> 
> org.apache.tomcat.embed
> tomcat-embed-core
> ${tomcat-embedded.version}
> 
> 
> org.apache.tomcat.embed
> tomcat-embed-el
> ${tomcat-embedded.version}
> 
> 
> org.apache.tomcat
> tomcat-annotations-api
> ${tomcat-embedded.version}
> 
>
>
> The result is the same
>
> I also checked status of the sockets on server with the netstat command.
>
> The number of ESTABLISHED is constantly and rapidly growing.
>
> Note, the problem is reproduced as a result of load testing.
>
>
> ср, 20 февр. 2019 г. в 01:40, Christopher Schultz <
> ch...@christopherschultz.net>:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > Иналь,
> >
> > On 2/19/19 12:12, Иналь Кятов wrote:
> > > I encountered a problem with embedded tomcat 8.5.29 (part of spring
> > > boot 1.5).
> >
> > Can you retest with the current version of 8.5.x? Current version is
> > 8.5.38, released 2019-02-11.
> >
> > - -chris
> > -BEGIN PGP SIGNATURE-
> > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
> >
> > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxshcsACgkQHPApP6U8
> > pFgaVg//TF4/DVpFjtTLk+d6Z/AOcFX7SEYg/0SEKjpKtxaUr5+19umt5mMi+Zqk
> > UkkCSB19KRpqLUY8o53xlgqL9SqqBF14Wh0T2FYqpXtKSfV/Nv6tvsEV6Bd9LqTz
> > /RSFcAmCTL+SDIwXQ4FzmW55aaPfous9lKgPYdZlYy4UwVvG7PP/EOD7swR470eU
> > DmvjkkOKPJ87mSFra3LJ5MxrvLAw+9PgEACLc4nF6Tkceisn7kTIP/s7SGKb4Few
> > PWXYKy7NfcBASMYfikS/SAdCHNbjD9Za+L6okTuUjjvlNwAQvM7BWnG2CurpX8wQ
> > oEinp/4OsXaD0yZ/pi+dmUOUS/AwSuaxD4YZWembSEvTW658bc+5YgpfcOLivcO+
> > iB4/erdLHW8dLW07Nl2EafTXvKTOXHNlL4HIrTLzoi8SlJ2b+j4U3/9b5LBke2TG
> > HpQSo7MxqVfllhDTiwsYMRIkPupZEqR41x8wG4CpcfpQjXJMmAvaeFpBQA0ZnVyn
> > OkbYDi3IF9C8uAd0sbEx2npZ05ptb8zyHmU0mTawBDSL/e+3xbcFvZ2v0LNujgVB
> > VqJdtXOJKRA66l6dN+nS377guMeL5BQJS4PeRMIapWotJbuCE2nYgcjcie3ipClq
> > SP00v4Vd85g4D5XPAWewoWJXRiOPMp1dc5pTYwviTgG6FNGtoCE=
> > =wHth
> > -END PGP SIGNATURE-
> >



-- 
WBR
Maxim aka solomax

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

Re: Fwd: websocket connections consume too much memory

[Иналь Кятов]

I retest with


*8.5.38*

...


org.apache.tomcat.embed
tomcat-embed-websocket
${tomcat-embedded.version}


org.apache.tomcat.embed
tomcat-embed-core
${tomcat-embedded.version}


org.apache.tomcat.embed
tomcat-embed-el
${tomcat-embedded.version}


org.apache.tomcat
tomcat-annotations-api
${tomcat-embedded.version}



The result is the same

I also checked status of the sockets on server with the netstat command.

The number of ESTABLISHED is constantly and rapidly growing.

Note, the problem is reproduced as a result of load testing.


ср, 20 февр. 2019 г. в 01:40, Christopher Schultz <
ch...@christopherschultz.net>:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Иналь,
>
> On 2/19/19 12:12, Иналь Кятов wrote:
> > I encountered a problem with embedded tomcat 8.5.29 (part of spring
> > boot 1.5).
>
> Can you retest with the current version of 8.5.x? Current version is
> 8.5.38, released 2019-02-11.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxshcsACgkQHPApP6U8
> pFgaVg//TF4/DVpFjtTLk+d6Z/AOcFX7SEYg/0SEKjpKtxaUr5+19umt5mMi+Zqk
> UkkCSB19KRpqLUY8o53xlgqL9SqqBF14Wh0T2FYqpXtKSfV/Nv6tvsEV6Bd9LqTz
> /RSFcAmCTL+SDIwXQ4FzmW55aaPfous9lKgPYdZlYy4UwVvG7PP/EOD7swR470eU
> DmvjkkOKPJ87mSFra3LJ5MxrvLAw+9PgEACLc4nF6Tkceisn7kTIP/s7SGKb4Few
> PWXYKy7NfcBASMYfikS/SAdCHNbjD9Za+L6okTuUjjvlNwAQvM7BWnG2CurpX8wQ
> oEinp/4OsXaD0yZ/pi+dmUOUS/AwSuaxD4YZWembSEvTW658bc+5YgpfcOLivcO+
> iB4/erdLHW8dLW07Nl2EafTXvKTOXHNlL4HIrTLzoi8SlJ2b+j4U3/9b5LBke2TG
> HpQSo7MxqVfllhDTiwsYMRIkPupZEqR41x8wG4CpcfpQjXJMmAvaeFpBQA0ZnVyn
> OkbYDi3IF9C8uAd0sbEx2npZ05ptb8zyHmU0mTawBDSL/e+3xbcFvZ2v0LNujgVB
> VqJdtXOJKRA66l6dN+nS377guMeL5BQJS4PeRMIapWotJbuCE2nYgcjcie3ipClq
> SP00v4Vd85g4D5XPAWewoWJXRiOPMp1dc5pTYwviTgG6FNGtoCE=
> =wHth
> -END PGP SIGNATURE-
>

Re: Fwd: websocket connections consume too much memory

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Иналь,

On 2/19/19 12:12, Иналь Кятов wrote:
> I encountered a problem with embedded tomcat 8.5.29 (part of spring
> boot 1.5).

Can you retest with the current version of 8.5.x? Current version is
8.5.38, released 2019-02-11.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxshcsACgkQHPApP6U8
pFgaVg//TF4/DVpFjtTLk+d6Z/AOcFX7SEYg/0SEKjpKtxaUr5+19umt5mMi+Zqk
UkkCSB19KRpqLUY8o53xlgqL9SqqBF14Wh0T2FYqpXtKSfV/Nv6tvsEV6Bd9LqTz
/RSFcAmCTL+SDIwXQ4FzmW55aaPfous9lKgPYdZlYy4UwVvG7PP/EOD7swR470eU
DmvjkkOKPJ87mSFra3LJ5MxrvLAw+9PgEACLc4nF6Tkceisn7kTIP/s7SGKb4Few
PWXYKy7NfcBASMYfikS/SAdCHNbjD9Za+L6okTuUjjvlNwAQvM7BWnG2CurpX8wQ
oEinp/4OsXaD0yZ/pi+dmUOUS/AwSuaxD4YZWembSEvTW658bc+5YgpfcOLivcO+
iB4/erdLHW8dLW07Nl2EafTXvKTOXHNlL4HIrTLzoi8SlJ2b+j4U3/9b5LBke2TG
HpQSo7MxqVfllhDTiwsYMRIkPupZEqR41x8wG4CpcfpQjXJMmAvaeFpBQA0ZnVyn
OkbYDi3IF9C8uAd0sbEx2npZ05ptb8zyHmU0mTawBDSL/e+3xbcFvZ2v0LNujgVB
VqJdtXOJKRA66l6dN+nS377guMeL5BQJS4PeRMIapWotJbuCE2nYgcjcie3ipClq
SP00v4Vd85g4D5XPAWewoWJXRiOPMp1dc5pTYwviTgG6FNGtoCE=
=wHth
-END PGP SIGNATURE-

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

Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Pawel,

On 2/7/19 19:41, Pawel Veselov wrote:
> Sorry for a rather rude intrusion.

If you think it's rude, why did you do it?

> On Thu, Feb 7, 2019 at 4:18 PM Christopher Schultz 
>  wrote:
> 
>> Chunked encoding is like sending a bunch of small HTTP
>> message-pieces (I have to be careful about my wording here, since
>> "part" actually means something in multipart messages
> 
> May be just "chunks"? :)

Defining a word using the word itself is circular-reasoning. If you
looked-up  "chunk" in the dictionary and it said: "Chunk: (n) chunk",
you'd be kind of lost, wouldn't you?

>> Then, you send each chunk with a chunk size (in decimal bytes), a
>> CRLF pair, then your content, and another CRLF pair. The final
>> chunk has a length of 0 (zero):
>> 
>> 32 [32 bytes of data] 128 [128 bytes of data] 0
> 
> Chunk sizes are expressed in hexadecimal notation, though, not
> decimal.

Yes, thank you for the correction. Those numbers should have been:

20
[32 bytes of data]
80
[128 bytes of data]
0


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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxdkOAACgkQHPApP6U8
pFgxQBAAk8GXkkc4bXp0Uf4JmaBtxthDrRIqs6eUx6wqjQdeJgTCAGUIF4274j9k
bmfaYWx0d4/ZZ4yibrD/7RjSn3ezSaE69x1beYs7UaFZTdooA8azspMCgh0iDmx1
OcbYFpo2qjrsA0GIoxmP8qBbSCXV/guw/OmCRmj4LFBV3hc5+ADu4ioxcko6jWSa
hNxmBNcpH8nlUqeNeb3bSK/fh1FKBHQFEVe46KI0dXkYVoTNfoTqKohxyzRpMh/h
xhMb0MWyad04F6k0gBuoaCnzsuq5ZKdnKRXuslpidhFT3Jc2/NdGBpQcYhjYoGgT
2PHVgrlshu+CTl5Gn/6KvFUGE2O0yyRuirpv6iQZ9kQ/3Gn3FlrgT5ZxhHbRZ1B7
7a98TegGyRn5KQ4YvJkpjGljtkfxBjjRfvA1NBhdHRplUuaxB4U/mROccDCVXVr9
YybUVGNwP1Zd4no8B4NKtDyAGXFtgkJz/SCCmZ4F5EYkCAXLRnNZ27nXfrA6XYYO
QxOe7XaAy9PMKiaW7L+wIevHeXPhrPlgus4usS/F1ZelDxY6nY1oekJmpCTX4gnm
HlgrLIA35YGPjQGVhqtvQhJGSg+JQGIX5Azj98fjJ0hypy1obHXOtvCe+/O93i/q
OsRj9gcxXybTTp24G1U8J03p0s+o3q7gb9Tf9La/AqrB4hvpZLA=
=1Oqx
-END PGP SIGNATURE-

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

Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request

[Pawel Veselov]

Sorry for a rather rude intrusion.

On Thu, Feb 7, 2019 at 4:18 PM Christopher Schultz
 wrote:

> Chunked encoding is like sending a bunch of small HTTP message-pieces
> (I have to be careful about my wording here, since "part" actually
> means something in multipart messages

May be just "chunks"? :)

> Then, you send each chunk with a chunk size (in decimal bytes), a CRLF
> pair, then your content, and another CRLF pair. The final chunk has a
> length of 0 (zero):
>
> 32
> [32 bytes of data]
> 128
> [128 bytes of data]
> 0

Chunk sizes are expressed in hexadecimal notation, though, not decimal.

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

Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request

[Bhavesh Mistry]

Hi Chuck,

Thank for your answer and details explanation.  We have requested our
customer to fix the wrong client.  Are there any logs we can see if the
content length does not match?

Once again thanks for your help!

Thanks,
Bhavesh

On Thu, Feb 7, 2019 at 4:03 PM Caldarale, Charles R <
chuck.caldar...@unisys.com> wrote:

> > From: Bhavesh Mistry [mailto:mistry.p.bhav...@gmail.com]
> > Subject: Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length
> Corrupting
> > Parsing logic for Subsequent Request
>
> > I am stating following when you have request/response on the same TCP
> > connection.  for example,
>
> > My understanding (please correct me if my wrong):
>
> It's wrong.  All TCP traffic, including HTTP requests, is a stream of
> bytes.
> There are no indications where one request ends and another starts other
> than the content length in each request.  If the malformed request
> specifies
> a length smaller than the actual content size, the next request will appear
> to start somewhere in the content stream.  Similarly, if the
> request-specified content length is larger than the sent size, the
> connector
> consumes part of the next request as the content of the prior.  There is no
> way for a server to correct this client misbehavior, other than by the
> server administrator disabling keep-alive - with serious performance
> impacts
> for well-mannered clients.  Fix your broken client.
>
>   - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you
> received
> this in error, please contact the sender and delete the e-mail and its
> attachments from all computers.
>
>

Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Bhavesh,

On 2/7/19 19:11, Christopher Schultz wrote:
> The Content-Length of the PUT request says "I'm going to send 128 
> bytes". The server is required to accept exactly 128 bytes, no more
> no less.

There is another option, here, but also requires that the client still
not be broken.

Instead of guessing at the Content-Length and then being wrong about
it, you can use "chunked" encoding.

Chunked encoding is like sending a bunch of small HTTP message-pieces
(I have to be careful about my wording here, since "part" actually
means something in multipart messages), each with its own Content-Length
.

First, you send the request like this:

PUT /foo/bar HTTP/1.1
Host: example.com
Connection: keep-alive
Transfer-Encoding: chunked

Then, you send each chunk with a chunk size (in decimal bytes), a CRLF
pair, then your content, and another CRLF pair. The final chunk has a
length of 0 (zero):

32
[32 bytes of data]
128
[128 bytes of data]
0

(this is the end of the message)

This is great for streaming, because you might not know the size of
the content before you have generated it all. Buffering the whole
message might be impractical.

If the client's problem is that it's not sure what the Content-Length
should be until the message is sent, then you can use chunked encoding
to solve that problem.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxcyu8ACgkQHPApP6U8
pFhTqg/+Jepl5JnlqViLSh15wyFBYwnBWEiR+d+12B6+21XtJP14yIaw6pnCp0FW
cc/SkLeUl4qywcqRp0f3af8Ub3hb9tE7VB8kMwGiNinUvWp0oDe6kRh8fBBXpHPo
Q/0Sk0OtZS1cHZt2zmzFe5ml8iWn86YPOUVBKuFRCt9yo8630HG/EVD8TZ181FyJ
JbySM+dfkQkhGhow6T59YMR0MxH0FembPnXQ3PQu8NSpmJ+r/7cAbnI0emmNjbNj
xne956Wfb9gIINZI7ch7dmpJcwC4yX7jAibt2f/OFwQ1hrp8XFUPBZpvEjEH2JDp
Y0+wxJ2pAaedqaLwtkob4xo+R6ZGYuyNEn43jM56CqIZV1qfUhVquUTaWkLi6uKy
lwyHTaHxwKQPhdu6y7qQ+aZfoOp6/TLz5Os6OkjTEbixY120jrTPx1FTvq8rSI07
K3V4FvvCQz7cmfv2ya0aUBKnvCT+LytWKDfdLye8TRX0y8QFVC1n+8mGOEdL1vcl
SPa/tCXtmhpJ/LS+n+fQPsqhV+niLc2fFhgUeVZGDv/uFo3BH/8rOCLJLo7N5jg3
GXRoLql0NQX2amdkbzPniY4+mvw/8lRwZeH+4JPfJeBeAIfhY4hIb1taNreTcEN7
sPZAl29SogZuARJG8ch9ZJkV8gfpGjZebfgzJLSMh3g7aIOHA9I=
=ZG7h
-END PGP SIGNATURE-

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

Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Bhavesh,

On 2/7/19 18:40, Bhavesh Mistry wrote:
> Hi Mark,
> 
> I understand what you are stating the root of issue originated with
> the client (wrong client).  I am stating following when you have 
> request/response on the same TCP connection.  for example,
> 
> My understanding (please correct me if my wrong):
> 
> Client ---SAME TCP 
> SOCKET--Server 1)PUT API 
> Content-Lenght: 419 2)server reads header and content body
> 
> Response 2XX
> 
> 3)Client Read response.
> 
> 4)Client SEND GET Request
> 
> GET API  HTTP1/1.1
> 
> 5) Server reads it (now tomcat reads request GET request due to
> the position of previous wrong content) CAN reset position of
> reading here?
No, Tomcat cannot do this. How does Tomcat know that the previous
request has actually NOT ended? What happens if the request looks like
this:

PUT /foo/bar
Host: example.com
Connection: keep-alive
Content-Length: 128
[64 bytes of whatever]

GET /goo/bar
Host: example.com
Connection: keep-alive
Content-Length: [...]

That looks like two requests, but it's only one. Why? Because the
Content-Length is (in this case, intentionally) wrong.

The Content-Length of the PUT request says "I'm going to send 128
bytes". The server is required to accept exactly 128 bytes, no more no
less. (Most servers will fail due to a timeout if the content is too
*short* and the end of the message never arrives.) That 128 bytes
extends beyond the 64 bytes actually sent and into the "next" request.
There is no magic "end of file" byte that the client can send to say
"yes, I know I said I was going to send you 128 bytes  but I changed
my mind at the last second and well, sorry". That just doesn't exist
in HTTP.

The same is true with a pair of requests like this:

PUT /foo/bar
Host: example.com
Connection: keep-alive
Content-Length: 32
0123456789abcde
0123456789abcde
0123456789abcde
0123456789abcde

GET /goo/bar
Host: example.com
Connection: keep-alive
Content-Length: [...]

That's two requests, but the second request starts with the text
"0123456789abcde" and not "GET /foo/bar", because the first request
sent too much data. The server is *required* to stop after
Content-Length bytes, full stop.

It is NOT in the spec that the server should ignore text in a request
that looks like garbage until it sees something like "GET "...

> 6) The server sends 400 with a close connection. 7) Client Read
> response.
> 
> So, if you look request/response model,  how can tomcat read ahead
> on PUT call on a socket the data is not there?

It's not reading "ahead". The data is already there, and it looks like
a pipelined request from the client.

Your problem is that you are thinking that the software is smarter
than it is. Just because it's obvious to YOU what is going on doesn't
mean that the HTTP specification agrees with your opinion about how
things should work.

I often call this type of thing "do-what-I-mean semantics". It
generally means that the person who wants a job done can't articulate
exactly how to do it with instructions for all the edge cases and so
they just say "I want it to do the right thing all the time" --
usually by reading the mind of the user. It's tough to implement
requirements like that.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxcyTMACgkQHPApP6U8
pFiiOg/+LYfuwLdumv9JKCmSU2cSCOt4sAOivGwI3YS+XLX2RUy04GIpYEHQm6kb
xHEOmo2krIhnSGqjnZnWJtsJdqlSHxLNtBu53pXxKa72fq6GtsGweCzDqxZUmvS5
iZxKIfSBMqdN8urg8zBTp7WlrP2Gu97F/5XvN9jTX5cgA6FbgHkfhkq0m34rM43K
iQ7KetqMzgwVX4kVG9VEt3jJv/1cNNfHIZlhDU2RRlFh3ZV0S0eXnbjDE80jcsfI
OkWQDKhqnRKMTunvzYaZ6aCsweQl7VVcw+QQRu8n/LMtvt85p/WVI6sMR//Kjl+T
ij+l9v8GVbEFfmAK034hbQCfb+7x/0HH6uEA4U0nAoa090fIQLFk8aScy2gTRnaW
25dJ3kEnqGiD90mGsEpuyTD+kWjW6VtRk0XYxaPmCCXODAiPHPsvTNRYa40V6IJh
h3lAVpE3/LGpWgGnjNTcw/yXpRYC33xg0B8HPWdJWB+1EK2IpKcfrIp159vPt5YJ
V2ZABGVkd3kQ8qgpCCi7ibM4mIoI6RJrRJddXb2h2U8mhDn7ZaMFFGnaNJZi+rej
JGdc0or9av/tZLKQLGYZlYSyU2yw8b3yCXApxjH4uC61mIl6pXjNmI4r1EMHd+58
SmH8dWU5vfXmFwRYr727Zp6NMioqldEM8ET2V1xi8UWPYVM1A0s=
=jEde
-END PGP SIGNATURE-

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

RE: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request

[Caldarale, Charles R]

> From: Bhavesh Mistry [mailto:mistry.p.bhav...@gmail.com] 
> Subject: Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length
Corrupting 
> Parsing logic for Subsequent Request

> I am stating following when you have request/response on the same TCP 
> connection.  for example,

> My understanding (please correct me if my wrong):

It's wrong.  All TCP traffic, including HTTP requests, is a stream of bytes.
There are no indications where one request ends and another starts other
than the content length in each request.  If the malformed request specifies
a length smaller than the actual content size, the next request will appear
to start somewhere in the content stream.  Similarly, if the
request-specified content length is larger than the sent size, the connector
consumes part of the next request as the content of the prior.  There is no
way for a server to correct this client misbehavior, other than by the
server administrator disabling keep-alive - with serious performance impacts
for well-mannered clients.  Fix your broken client.

  - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.



smime.p7s
Description: S/MIME cryptographic signature

Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request

[Bhavesh Mistry]

Hi Mark,

I understand what you are stating the root of issue originated with the
client (wrong client).  I am stating following when you have
request/response on the same TCP connection.  for example,

My understanding (please correct me if my wrong):

Client ---SAME TCP
SOCKET--Server
1)PUT API
Content-Lenght: 419
2)server reads header and content body

 Response 2XX

3)Client Read response.

4)Client SEND GET Request

GET API  HTTP1/1.1
   5) Server reads it (now tomcat reads request GET request
due to the

   position of previous wrong content
)  CAN reset position of reading here?


  6) The server sends 400 with a close
connection.
7) Client Read response.

So, if you look request/response model,  how can tomcat read ahead on PUT
call on a socket the data is not there?



Thanks,

Bhavesh


On Thu, Feb 7, 2019 at 1:51 PM Mark Thomas  wrote:

> On 07/02/2019 20:05, Bhavesh Mistry wrote:
> > Hi Mark,
> >
> > There is no way to validate the END of a request for PUT call and if
> > Content-Lenght does not match what client had sent payload body then
> > rejected it and reset position.
>
> You can't do that. The only way to determine how much data to expect is
> from the content-length header. The server has no way to determine (with
> any certainty) that the client has stopped sending the previous request
> body (or hasn't sent any body at all) and is starting to send a new
> request.
>
> >
> > If content length does match then reject PUT request,
>
> Not possible.
>
> > and then close the
> > connection for PUT call not for subsequent request.   How can you read
> > ahead from TCP socket that does not have data yet for the next request?
>
> The server is going to do a blocking read (this is Servlet I/O so it is
> blocking) for more data. Again, the server has no way of knowing that
> the data that arrives is for a new request rather than the request body
> it was expecting.
>
> >  It
> > request/response model so PUT request processed with wrong content length
> > should not impact the next request.
>
> HTTP doesn't work like that.
>
> >  Another server like Jetty has no issue.
>
> The only way to guarantee that is to disable HTTP keep-alive. And I
> would be amazed if the Jetty folks did that by default.
>
> I suspect what you are seeing are the effects of different read
> timeouts. If the connection times out waiting for the client to send the
> data *before* the client tries to send the next request you'll get the
> behaviour you describe.
>
> The problem is that the server can't differentiate between slow clients
> and misbehaving clients so by lowering the timeout to work-around the
> broken clients you may end up breaking slower clients unintentionally.
>
> As I said, your best solution is to fix the broken client.
>
> Mark
>
> >
> > Our use case:
> > Client --> Jetty ---> Apache-Camel HTTP Proxy ---> tomcat (Spring
> boot).
> >
> > The failure on the SAME TCP occurs at tomcat, not at Jetty for the same
> TCP
> > connection.
> >
> >
> > Thanks,
> > Bhavesh
> >
> >
> > On Thu, Feb 7, 2019 at 11:25 AM Mark Thomas  wrote:
> >
> >> On 07/02/2019 18:48, Bhavesh Mistry wrote:
> >>> Hello Tomcat Developers,
> >>>
> >>> I have a unique situation about HTTP Protocol PAYLOAD parsing and
> >>> Content-Length Header.
> >>
> >> There is nothing unique here.
> >>
> >>>  When PUT/POST Content-Length is NOT correct
> >>> (client send wrong Content-Lenght), the tomcat is able to parse the
> >>> request and respond to request with 2xx but subsequent on SAME TCP
> >>> connection fails with corrupted HTTP HEADER.
> >>
> >> As expected.
> >>
> >> Tomcat can't read minds. If the content length header is not correct,
> >> Tomcat can't correctly identify the end of the request so it is going to
> >> read too much / too little and - on a keep-alive connection - the next
> >> request is going to fail.
> >>
> >> There is nothing unusual about this.
> >>
> >> There is no Tomcat bug here.
> >>
> >> You need to fix the broken client so the content-length is correctly
> set.
> >>
> >> You could disable keep-alive connections. That would limit the failures
> >> to the faulty requests but at the cost of reduced performance.
> >>
> >> Mark
> >>
> >> -
> >> 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: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request

[Mark Thomas]

On 07/02/2019 20:05, Bhavesh Mistry wrote:
> Hi Mark,
> 
> There is no way to validate the END of a request for PUT call and if
> Content-Lenght does not match what client had sent payload body then
> rejected it and reset position.

You can't do that. The only way to determine how much data to expect is
from the content-length header. The server has no way to determine (with
any certainty) that the client has stopped sending the previous request
body (or hasn't sent any body at all) and is starting to send a new request.

> 
> If content length does match then reject PUT request,

Not possible.

> and then close the
> connection for PUT call not for subsequent request.   How can you read
> ahead from TCP socket that does not have data yet for the next request?

The server is going to do a blocking read (this is Servlet I/O so it is
blocking) for more data. Again, the server has no way of knowing that
the data that arrives is for a new request rather than the request body
it was expecting.

>  It
> request/response model so PUT request processed with wrong content length
> should not impact the next request.

HTTP doesn't work like that.

>  Another server like Jetty has no issue.

The only way to guarantee that is to disable HTTP keep-alive. And I
would be amazed if the Jetty folks did that by default.

I suspect what you are seeing are the effects of different read
timeouts. If the connection times out waiting for the client to send the
data *before* the client tries to send the next request you'll get the
behaviour you describe.

The problem is that the server can't differentiate between slow clients
and misbehaving clients so by lowering the timeout to work-around the
broken clients you may end up breaking slower clients unintentionally.

As I said, your best solution is to fix the broken client.

Mark

> 
> Our use case:
> Client --> Jetty ---> Apache-Camel HTTP Proxy ---> tomcat (Spring boot).
> 
> The failure on the SAME TCP occurs at tomcat, not at Jetty for the same TCP
> connection.
> 
> 
> Thanks,
> Bhavesh
> 
> 
> On Thu, Feb 7, 2019 at 11:25 AM Mark Thomas  wrote:
> 
>> On 07/02/2019 18:48, Bhavesh Mistry wrote:
>>> Hello Tomcat Developers,
>>>
>>> I have a unique situation about HTTP Protocol PAYLOAD parsing and
>>> Content-Length Header.
>>
>> There is nothing unique here.
>>
>>>  When PUT/POST Content-Length is NOT correct
>>> (client send wrong Content-Lenght), the tomcat is able to parse the
>>> request and respond to request with 2xx but subsequent on SAME TCP
>>> connection fails with corrupted HTTP HEADER.
>>
>> As expected.
>>
>> Tomcat can't read minds. If the content length header is not correct,
>> Tomcat can't correctly identify the end of the request so it is going to
>> read too much / too little and - on a keep-alive connection - the next
>> request is going to fail.
>>
>> There is nothing unusual about this.
>>
>> There is no Tomcat bug here.
>>
>> You need to fix the broken client so the content-length is correctly set.
>>
>> You could disable keep-alive connections. That would limit the failures
>> to the faulty requests but at the cost of reduced performance.
>>
>> Mark
>>
>> -
>> 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: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request

[Bhavesh Mistry]

Hi Mark,

There is no way to validate the END of a request for PUT call and if
Content-Lenght does not match what client had sent payload body then
rejected it and reset position.

If content length does match then reject PUT request, and then close the
connection for PUT call not for subsequent request.   How can you read
ahead from TCP socket that does not have data yet for the next request?  It
request/response model so PUT request processed with wrong content length
should not impact the next request.

 Another server like Jetty has no issue.

Our use case:
Client --> Jetty ---> Apache-Camel HTTP Proxy ---> tomcat (Spring boot).

The failure on the SAME TCP occurs at tomcat, not at Jetty for the same TCP
connection.


Thanks,
Bhavesh


On Thu, Feb 7, 2019 at 11:25 AM Mark Thomas  wrote:

> On 07/02/2019 18:48, Bhavesh Mistry wrote:
> > Hello Tomcat Developers,
> >
> > I have a unique situation about HTTP Protocol PAYLOAD parsing and
> > Content-Length Header.
>
> There is nothing unique here.
>
> >  When PUT/POST Content-Length is NOT correct
> > (client send wrong Content-Lenght), the tomcat is able to parse the
> > request and respond to request with 2xx but subsequent on SAME TCP
> > connection fails with corrupted HTTP HEADER.
>
> As expected.
>
> Tomcat can't read minds. If the content length header is not correct,
> Tomcat can't correctly identify the end of the request so it is going to
> read too much / too little and - on a keep-alive connection - the next
> request is going to fail.
>
> There is nothing unusual about this.
>
> There is no Tomcat bug here.
>
> You need to fix the broken client so the content-length is correctly set.
>
> You could disable keep-alive connections. That would limit the failures
> to the faulty requests but at the cost of reduced performance.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request

[Mark Thomas]

On 07/02/2019 18:48, Bhavesh Mistry wrote:
> Hello Tomcat Developers,
> 
> I have a unique situation about HTTP Protocol PAYLOAD parsing and
> Content-Length Header.

There is nothing unique here.

>  When PUT/POST Content-Length is NOT correct
> (client send wrong Content-Lenght), the tomcat is able to parse the
> request and respond to request with 2xx but subsequent on SAME TCP
> connection fails with corrupted HTTP HEADER.

As expected.

Tomcat can't read minds. If the content length header is not correct,
Tomcat can't correctly identify the end of the request so it is going to
read too much / too little and - on a keep-alive connection - the next
request is going to fail.

There is nothing unusual about this.

There is no Tomcat bug here.

You need to fix the broken client so the content-length is correctly set.

You could disable keep-alive connections. That would limit the failures
to the faulty requests but at the cost of reduced performance.

Mark

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

Re: Fwd: Tomcat question

[Ognjen Blagojevic]

Zahi,

On 30.4.2018. 11:09, Zahi Fail wrote:

curl -X POST \
   http://localhost:8080/userManagement/rest/Traffic/users2 \
   -H 'Authorization: Basic dG9tY2F0OnMzY3JldA==' \
   -H 'Cache-Control: no-cache' \
   -H 'Content-Type: application/json' \
   -H 'Postman-Token: 71819f33-6206-02c5-5cf2-8de6347fc154' \
   -d '[{"id":1, "code":2, "time":"2009-02-15", "cycleSecond":22,
"programNumber":1221, "stageNumber":22, "moves":"22",
"detectors":"fead","conditions":"2ddsa"}]'


First, please don't top post. Read mailing list guidelines here:

  http://tomcat.apache.org/lists.html#tomcat-users

Regarding the problem, base64 string "dG9tY2F0OnMzY3JldA==" decodes to 
"tomcat:s3cret", which is, according to your previously posted 
tomcat-users.xml file, user in the role "manager-gui".


On the other hand, your web.xml auth-constraint configuration expects 
the user in the role "manager".


-Ognjen

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

Re: Fwd: Tomcat question

[Zahi Fail]

This is the curl message from postman:

curl -X POST \
  http://localhost:8080/userManagement/rest/Traffic/users2 \
  -H 'Authorization: Basic dG9tY2F0OnMzY3JldA==' \
  -H 'Cache-Control: no-cache' \
  -H 'Content-Type: application/json' \
  -H 'Postman-Token: 71819f33-6206-02c5-5cf2-8de6347fc154' \
  -d '[{"id":1, "code":2, "time":"2009-02-15", "cycleSecond":22,
"programNumber":1221, "stageNumber":22, "moves":"22",
"detectors":"fead","conditions":"2ddsa"}]'

On Mon, Apr 30, 2018 at 11:42 AM, Ognjen Blagojevic <
ognjen.d.blagoje...@gmail.com> wrote:

> Zahi,
>
> On 25.4.2018. 13:19, zahi.f...@gmail.com wrote:
>
>> I configured in my conf\server.xml file the realm as below:
>>>
>>
> Ok, so the configuration looks fine.
>
> You said you are using Postman to send the request. Can you paste the
> `curl` command that the postman can generate for you just to check if it
> looks Ok?
>
> For instance, this would be the right curl command:
>
>   curl -u admin:falcon -X POST http://your.server/webapp/
>
> While those are not:
>
>   curl -u admin:falco -X POST http://your.server/webapp/ (typo in
> password, HTTP 401)
>
>   curl -X POST http://your.server/webapp/ (no credentials specified, HTTP
> 401)
>
>   curl -u tomcat:s3cret -X POST http://your.server/webapp/ (wrong role,
> HTTP 403)
>
>   curl -u admin:falcon -X GET http://your.server/webapp/ (GET instead of
> POST, HTTP status code... it depends)
>
> -Ognjen
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Fwd: Tomcat question

[Ognjen Blagojevic]

Zahi,

On 25.4.2018. 13:19, zahi.f...@gmail.com wrote:

I configured in my conf\server.xml file the realm as below:


Ok, so the configuration looks fine.

You said you are using Postman to send the request. Can you paste the 
`curl` command that the postman can generate for you just to check if it 
looks Ok?


For instance, this would be the right curl command:

  curl -u admin:falcon -X POST http://your.server/webapp/

While those are not:

  curl -u admin:falco -X POST http://your.server/webapp/ (typo in 
password, HTTP 401)


  curl -X POST http://your.server/webapp/ (no credentials specified, 
HTTP 401)


  curl -u tomcat:s3cret -X POST http://your.server/webapp/ (wrong role, 
HTTP 403)


  curl -u admin:falcon -X GET http://your.server/webapp/ (GET instead 
of POST, HTTP status code... it depends)


-Ognjen



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

Re: Fwd: Content-Type is turned to lower when passed through mod_jk - this looks to be a bug.

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 10/15/17 6:54 PM, Mark O'Donohue wrote:
> Hi
> 
> Just wanted an opinion on this before I logged a bug report against
> mod_jk.c
> 
> 
> Running our proxied request via mod_jk we are seeing the returned
> content-type being changing to all lowercase:
> 
> eg:
> 
> Content-Type: application/xxx..+*JSON*; charset=utf-8
> 
> to:
> 
> Content-Type: application/xxx..+*json*; charset=utf-8
> 
> 
> We thought this was tomcat at first, but turns out to be mod_jk.c
> that is the cause :
> 
> http://svn.apache.org/repos/asf/tomcat/jk/trunk/native/apache-2.0/mod_
jk.c
>
> 
> 
> 
> *for* *(*h *=* 0*;* h *<* num_of_headers*;* h*++)* *{*
> 
> *if* *(!*strcasecmp*(*header_names*[*h*],* "Content-type"*))* *{*
> 
> char ***tmp *=* apr_pstrdup*(*r*->*pool*,* header_values*[*h *]);*
> 
> ap_content_type_tolower*(*tmp*);*
> 
> /* It should be done like this in Apache 2.0 */
> 
> /* This way, Apache 2.0 will be able to set the output filter */
> 
> /* and it make jk useable with deflate using */
> 
> /* AddOutputFilterByType DEFLATE text/html */
> 
> ap_set_content_type*(*r*,* tmp*);*
> 
> *}*
> 
> 
> 
> Now on the validity of upper vs lower - it seems a little bit of a
> grey area:
> 
> https://www.w3.org/Protocols/rfc1341/4_Content-Type.html
> 
> 
> 
> The type, subtype, and parameter names are not case sensitive. For
> example, TEXT, Text, and TeXt are all equivalent. Parameter values
> are normally case sensitive, but certain parameters are interpreted
> to be case- insensitive, depending on the intended use. (For
> example, multipart boundaries are case-sensitive, but the "access-
> type" for message/External-body is not case-sensitive.)
> 
> 
> 
> 
> 
> But as a proxy we dont have an opinion - we just want to pass on
> what we get !
> 
> 
> Also if we run the request via mod_proxy/*mod_proxy_ajp.c* instead
> then the returned content-type header is *not *changed.
> 
> So should I open a bug against mod_jk for it?

I think the only bug here is that mod_jk is wasting time rewriting a
header that doesn't need to be modified.

But I see this strictly as a performance problem and not as a
spec-violation.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlno1p8ACgkQHPApP6U8
pFiUPw/+I4tz1k2pHGC5qW+f8e0+A3gEdfu4StL3b9Uwu5ci/eo3L0Z7oe7t2vXp
7ctifUCs8Ns8wGYj5QEwaR/8NKlgCavscG+jMzFdffsmszh+hPjzUa72q0IYKnHU
6Qc25xqj1Ru2/Iz1SV7t13T+t1ctfdE5wnB2RDC53F1ldA54/fwyLf2ActxdMW+K
XEH+9A+q203WriFIP4Ie1qD4M/x/7J57MBjp3dkbspfR2hmwGvESljXBuAKuDw8N
xpOt2bdXbnqNdHpVtOiHQxvyG9n4Vy69+/8Gd/fvpMsWoH/nJOG99xQ3IIsHieUG
ulLtn2Bb4RIgwGXCnV2cK0SCMPKoyYHMoFQ7fPQIbP3lXqhFtHsrYuGkzZ0ylk08
jqmV3e2VlB70Gd0iXUIhKZLEN1oWirUFZU8behhP75DWKWEAqZA1ThFBk9naG1RX
kLPWpVugB5Q1uLZulK34f5rRBmd85qceIYOfz30wNaT5pHfyumb7/MYoKE9l03lp
JcUg/UbG9XgfsQsC/vH/sSzCCFk89wtUgIqi9VjXQ4uomsJiutzmiyPvtVAYpcdI
v7qEFvvyVvXVuhU7xaygyAsLTQq4s/gHJ0Fx11Nx91iOCDwDEKLUkQZ3ZDcgQglI
Qjy4fcxeM4f7legRH7jhccUptzJZovbdOgMM1TCU8tiIIWFE2EQ=
=UpzH
-END PGP SIGNATURE-

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

Re: Fwd: [SECURITY] CVE-2017-12615 Apache Tomcat Remote Code Execution via JSP upload

[Mark Thomas]

On 22/09/17 10:36, Maarten van Hulsentop wrote:
> I have tried to reproduce this issue on a fresh tomcat 7.0.78 installation.
> The issue can indeed easily be reproduced on the default servlet by setting
> the readonly property to false. After that, it is possible to PUT the jsp
> and the GET request will execute.
> 
> When i change the default servlet to be the WebDAV servlet, it can not
> longer PUT the JSP because of 409 errors.
> Adjusting the servlet mapping from / to /* resolves the 409. But doing so
> seems to prevent the JSP execution; the GET request will just yield the
> contents of the JSP.
> What do i need to do to get it reproduced for the WebDAV servlet as well?
> Or is this a theoretical thing and can we consider the WebDAV servlet
> configured in scenario 3 as not vulnerable in the real world?

I haven't seen a PoC for exploiting this via Tomcat's WebDAV
implementation. The original advisory was based on an understanding of
the Default servlet PoC and a quick look at Tomcat's WebDAV code. A
closer inspection shows that the Default servlet PoC won't work with
Tomcat's WebDAV implementation.

It looks to be unlikely that Tomcat's WebDAV implementation is
exploitable but as far as I am aware there hasn't been a great deal of
investigation in that direction. At this point it seems prudent to
assume that WebDAV could be vulnerable and mitigate accordingly.

> Does this
> also apply for individual web applications configuring a similar web.xml or
> is it only reproducable on the global default servlet?

CVE-2017-12615 applies in either of the above scenarios.

Mark

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

Re: Fwd: [SECURITY] CVE-2017-12615 Apache Tomcat Remote Code Execution via JSP upload

[Maarten van Hulsentop]

Hello,

Op wo 20 sep. 2017 om 09:27 schreef Mark Thomas :

> On 19/09/17 14:10, Mark Thomas wrote:
> > On 19/09/17 14:00, André Warnier (tomcat) wrote:
> >> Hello.
> >>
> >> Did the issue below also affect the DAV application ?
> >
> > Yes, as the WebDAV servlet also processes HTTP PUT requests.
> >
> > The WebDAV servlet extends the Default servlet so they actually share
> > the implementation.
>
> Thinking about this a little more, it will depend on how the WebDAV
> servlet is mapped. While there is a configuration where this would be an
> issue for WebDAV, I don't think it is one that would normally be used.
>
> I have tried to reproduce this issue on a fresh tomcat 7.0.78 installation.
The issue can indeed easily be reproduced on the default servlet by setting
the readonly property to false. After that, it is possible to PUT the jsp
and the GET request will execute.

When i change the default servlet to be the WebDAV servlet, it can not
longer PUT the JSP because of 409 errors.
Adjusting the servlet mapping from / to /* resolves the 409. But doing so
seems to prevent the JSP execution; the GET request will just yield the
contents of the JSP.
What do i need to do to get it reproduced for the WebDAV servlet as well?
Or is this a theoretical thing and can we consider the WebDAV servlet
configured in scenario 3 as not vulnerable in the real world? Does this
also apply for individual web applications configuring a similar web.xml or
is it only reproducable on the global default servlet?

For clarity, my scenarios are;
1. == Default servlet reproduction
- [fresh installation Tomcat 7.0.78]
- Modify [tomcat]/conf/web.xml,
add 
readonlyfalse
to default
- PUT possible
- GET executes JSP -> vulnerable!

2. == WebDAV servlet reproduction with mapping on '/'
- [fresh installation Tomcat 7.0.78]
- Modify [tomcat]/conf/web.xml, change
to  org.apache.catalina.servlets.WebdavServlet
for default
- Modify [tomcat]/conf/web.xml,
add 
readonlyfalse
to default
- PUT fails with 409 message -> not vulnerable?

3. == WebDAV servlet reproduction with mapping on '/*'
- [fresh installation Tomcat 7.0.78]
- Modify [tomcat]/conf/web.xml, change to
org.apache.catalina.servlets.WebdavServlet
for default
- Modify [tomcat]/conf/web.xml,
add 
readonlyfalse
to default
- Modify [tomcat]/conf/web.xml, change url pattern
/ to /*
(for default)
- PUT possible
- GET retrieves the content for the JSP -> not vulnerable right now?

Thank you for your feedback,

Regards,

Maarten van Hulsentop

Re: Fwd: [SECURITY] CVE-2017-12615 Apache Tomcat Remote Code Execution via JSP upload

[Mark Thomas]

On 19/09/17 14:10, Mark Thomas wrote:
> On 19/09/17 14:00, André Warnier (tomcat) wrote:
>> Hello.
>>
>> Did the issue below also affect the DAV application ?
> 
> Yes, as the WebDAV servlet also processes HTTP PUT requests.
> 
> The WebDAV servlet extends the Default servlet so they actually share
> the implementation.

Thinking about this a little more, it will depend on how the WebDAV
servlet is mapped. While there is a configuration where this would be an
issue for WebDAV, I don't think it is one that would normally be used.

Mark


> 
>> And if yes, also only under Windows ?
> 
> Yes. This is, as far as we can tell, Windows specific.
> 
> HTH,
> 
> Mark
> 
> 
>>
>>  Forwarded Message 
>> Subject: [SECURITY] CVE-2017-12615 Apache Tomcat Remote Code Execution
>> via JSP upload
>> Date: Tue, 19 Sep 2017 11:58:44 +0100
>> From: Mark Thomas 
>> Reply-To: Tomcat Users List 
>> To: Tomcat Users List 
>> CC: annou...@tomcat.apache.org ,
>> annou...@apache.org, Tomcat Developers List 
>>
>> CVE-2017-7674 Apache Tomcat Remote Code Execution via JSP Upload
>>
>> Severity: Important
>>
>> Vendor: The Apache Software Foundation
>>
>> Versions Affected:
>> Apache Tomcat 7.0.0 to 7.0.79
>>
>> Description:
>> When running on Windows with HTTP PUTs enabled (e.g. via setting the
>> readonly initialisation parameter of the Default to false) it was
>> possible to upload a JSP file to the server via a specially crafted
>> request. This JSP could then be requested and any code it contained
>> would be executed by the server.
>>
>> Mitigation:
>> Users of the affected versions should apply one of the following
>> mitigations:
>> - Upgrade to Apache Tomcat 7.0.81 or later (7.0.80 was not released)
>>
>> Credit:
>> This issue was reported responsibly to the Apache Tomcat Security Team
>> by iswin from 360-sg-lab (360观星实验室)
>>
>> History:
>> 2017-09-19 Original advisory
>>
>> References:
>> [1] http://tomcat.apache.org/security-7.html
>>
>> -
>> 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: Fwd: [SECURITY] CVE-2017-12615 Apache Tomcat Remote Code Execution via JSP upload

[Thakur, Gulam (IBM)]

Hi,

This we require in windows systems. We will be looking at Windows 10. 
Springboot application in Microsoft Azure based.


Many thanks, 

Gulam Thakur
Software Developer, Synapse Dev Squad 
BP Sunbury, Bldg H, 1st floor
TW16 7LN







Many thanks, 

Gulam Thakur
Software Developer, Synapse Dev Squad 
BP Sunbury, Bldg H, 1st floor
TW16 7LN


Mobile: +44 (0) 7443 243808 
E-mail: gulam.tha...@bp.com
 gulam.thakur-cic...@ibm.com




BP International Limited. Registered office: Chertsey Road, Sunbury on Thames, 
Middlesex, TW16 7BP. Registered in England and Wales, number 542515. 
 
E-mail disclaimer: The information in this e-mail is confidential and may be 
legally privileged. It is intended solely for the addressee(s) only. Access to 
this e-mail by anyone else is unauthorised. If you are not the intended 
recipient, any disclosure, copying, distribution or an action taken or omitted 
to be taken in reliance on it, is prohibited and may be unlawful. Within the 
bounds of law, electronic transmissions through internal and external networks 
may be monitored to ensure compliance with internal policies and legitimate 
business purposes.

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: 19 September 2017 14:10
To: Tomcat Users List 
Subject: Re: Fwd: [SECURITY] CVE-2017-12615 Apache Tomcat Remote Code Execution 
via JSP upload

On 19/09/17 14:00, André Warnier (tomcat) wrote:
> Hello.
> 
> Did the issue below also affect the DAV application ?

Yes, as the WebDAV servlet also processes HTTP PUT requests.

The WebDAV servlet extends the Default servlet so they actually share the 
implementation.

> And if yes, also only under Windows ?

Yes. This is, as far as we can tell, Windows specific.

HTH,

Mark


> 
>  Forwarded Message 
> Subject: [SECURITY] CVE-2017-12615 Apache Tomcat Remote Code Execution 
> via JSP upload
> Date: Tue, 19 Sep 2017 11:58:44 +0100
> From: Mark Thomas 
> Reply-To: Tomcat Users List 
> To: Tomcat Users List 
> CC: annou...@tomcat.apache.org , 
> annou...@apache.org, Tomcat Developers List 
> 
> CVE-2017-7674 Apache Tomcat Remote Code Execution via JSP Upload
> 
> Severity: Important
> 
> Vendor: The Apache Software Foundation
> 
> Versions Affected:
> Apache Tomcat 7.0.0 to 7.0.79
> 
> Description:
> When running on Windows with HTTP PUTs enabled (e.g. via setting the 
> readonly initialisation parameter of the Default to false) it was 
> possible to upload a JSP file to the server via a specially crafted 
> request. This JSP could then be requested and any code it contained 
> would be executed by the server.
> 
> Mitigation:
> Users of the affected versions should apply one of the following
> mitigations:
> - Upgrade to Apache Tomcat 7.0.81 or later (7.0.80 was not released)
> 
> Credit:
> This issue was reported responsibly to the Apache Tomcat Security Team 
> by iswin from 360-sg-lab (360观星实验室)
> 
> History:
> 2017-09-19 Original advisory
> 
> References:
> [1] http://tomcat.apache.org/security-7.html
> 
> -
> 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: Fwd: [SECURITY] CVE-2017-12615 Apache Tomcat Remote Code Execution via JSP upload

[Mark Thomas]

On 19/09/17 14:00, André Warnier (tomcat) wrote:
> Hello.
> 
> Did the issue below also affect the DAV application ?

Yes, as the WebDAV servlet also processes HTTP PUT requests.

The WebDAV servlet extends the Default servlet so they actually share
the implementation.

> And if yes, also only under Windows ?

Yes. This is, as far as we can tell, Windows specific.

HTH,

Mark


> 
>  Forwarded Message 
> Subject: [SECURITY] CVE-2017-12615 Apache Tomcat Remote Code Execution
> via JSP upload
> Date: Tue, 19 Sep 2017 11:58:44 +0100
> From: Mark Thomas 
> Reply-To: Tomcat Users List 
> To: Tomcat Users List 
> CC: annou...@tomcat.apache.org ,
> annou...@apache.org, Tomcat Developers List 
> 
> CVE-2017-7674 Apache Tomcat Remote Code Execution via JSP Upload
> 
> Severity: Important
> 
> Vendor: The Apache Software Foundation
> 
> Versions Affected:
> Apache Tomcat 7.0.0 to 7.0.79
> 
> Description:
> When running on Windows with HTTP PUTs enabled (e.g. via setting the
> readonly initialisation parameter of the Default to false) it was
> possible to upload a JSP file to the server via a specially crafted
> request. This JSP could then be requested and any code it contained
> would be executed by the server.
> 
> Mitigation:
> Users of the affected versions should apply one of the following
> mitigations:
> - Upgrade to Apache Tomcat 7.0.81 or later (7.0.80 was not released)
> 
> Credit:
> This issue was reported responsibly to the Apache Tomcat Security Team
> by iswin from 360-sg-lab (360观星实验室)
> 
> History:
> 2017-09-19 Original advisory
> 
> References:
> [1] http://tomcat.apache.org/security-7.html
> 
> -
> 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: Fwd: Bug 56684 - java7: java.net.SocketTimeoutException: Accept timed out

[Mark Thomas]

On 06/07/17 13:22, Gagandeep Singh wrote:
> Hi All,
> 
> This is regarding the tomcat bug mentioned in subject. I have few questions
> as below regarding the same. Could anyone please help me understand.
> 
> - Would this issue only occur when the server has not been accessed for 50
> days, as I think it should reset the accept timer once it gets any request
> because a new accept() would be called then.

Yes.

> - Is there a way this issue can be reproduced quickly so that we don't have
> to wait for 50 days to see the issue ?

None I am aware of.

> - And would there be a way to check if the issue has been fixed after
> tomcat upgrade, other than waiting again for 50 days ?

None I am aware of.

Mark

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

Re: Fwd: tomcat automatically binds it to 0.0.0.0 from 127.0.0.1

[Rakesh Java]

Yes, It doesnt happens everytime and cannot reproducable

Any guess why this is happening ?

On Tue, Jun 20, 2017 at 7:01 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Rakesh,
>
> On 6/19/17 12:43 AM, Rakesh Java wrote:
> > Below is my netstat showing port bindings tcp 0 0 0.0.0.0:1234
> > 0.0.0.0:* LISTEN
>
> That doesn't show the pid or binary bound to port 1234.
>
> With this configuration:
>
> protocol="org.apache.coyote.http11.Http11NioProtocol"
> address="127.0.0.1"
>  secure="false"
> URIEncoding="UTF-8"
>executor="tomcatThreadPool" />
>
> I get a socket bound to 127.0.0.1:8216:
>
> > tcp6   0  0 127.0.0.1:8217  :::*   LISTEN
> > 8183/java
>
> ... but when I use this:
>
> protocol="org.apache.coyote.http11.Http11NioProtocol"
>  secure="false"
> URIEncoding="UTF-8"
>executor="tomcatThreadPool" />
>
> > tcp6   0  0 :::8217 :::*   LISTEN
> > 20591/java
>
> Environment:
> Tomcat 8.5.15
> Oracle Java 1.8.0_101 (most important factor)
> Linux kernel 2.6.32
>
> I'm not sure why it's not working for you. The Tomcat version
> shouldn't matter very much, since everything goes down to the JVM.
>
> - -chris
>
> > On Fri, Jun 16, 2017 at 9:55 PM, Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > Rakesh,
> >
> > On 6/16/17 5:48 AM, Rakesh Java wrote:
>  I have made a port( example 1234) to be bound to the local
>  host 127.0.0.1 .But when i restart tomcat automatically binds
>  it to 0.0.0.0 .
> 
> 
>  And my connector in server.xml contains 127.0.0.1 as address
>  .
> 
>    address="127.0.0.1" protocol="HTTP ...>
> 
>  My Tomcat Version
> 
>  Server version: Apache Tomcat/6.0.48 Server built:   Dec 12
>  2016 14:06:06 UTC Server number:  6.0.48.0 OS Name:
>  Linux JVM Version:1.8.0_111-b15 JVM Vendor: Oracle
>  Corporation
> 
> 
> 
>  Logs in Tomcat
> 
>  May 03, 2017 1:58:19 PM
>  org.apache.coyote.http11.Http11AprProtocol destroy INFO:
>  Stopping Coyote HTTP/1.1 on http-127.0.0.1-1234 ...
>  ... May 03, 2017 1:58:49 PM
>  org.apache.coyote.http11.Http11AprProtocol init INFO:
>  Initializing Coyote HTTP/1.1 on http-0.0.0.0-1234
> 
>  Can some one say why this issue is happening ? Best Regards,
>  Rakesh :-)
> >
> > Please show the netstat showing your port bindings.
> >
> > -chris
> >>
> >> -
> >>
> >>
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
> >
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAllJI8oACgkQHPApP6U8
> pFgLwQ/9H1GT8TKCfrQtyiDJTxYqzEv6u6O/ZFvub1pqgFGuzPN61qUD+QB8Kl2R
> iTM3VoxTYqlH15ZgSV5Roms6l6O9Hw6yZnFG9ooIp7Aerbc7uFJq6y57hmDVf3hd
> t8661gYajju4Z00WJ7y7o6SGTWVox6PUz6yyBHKSOpPmGJkN0Nauxiumh2dk9Mcv
> xPVAmVyzmIwiU8lb4EehCuYRBhviNxC9YvXjlBQ8sf8lswpEq7D6uH++Ye3LfgW9
> GecW0POSU3CpJM5bk6Rm/Dm9f3UBR9VgnGRxb9v5YGJE2JKZ7/n7p0yHr24I81RE
> rTGmA6AThP/nndCFKkc4tOFxDTTNSqXdSCyVrYP21Mgd/Ezx+vZNIN1hDJk3nMlM
> S3e95zQHfaZtrfXscSkBhRKq5bUMxK367vv+t649UWlfk+kY1cp93NIWxaTTES1q
> 7BU2bl67E0hfTj9XtKcFlUJ9e5BCpB8KXXUai1h9/ZCPW9fGdaOrVIhTrC6cPYPW
> 965dxjA+8i+O9suzLSVk/6R185WpKuiRSCsJdRwZt+4buS/8mQ/GmNJwa3mWBRgY
> CNBY9JocEagXvMw1j0VGghcs6pJYd3DISur9Q+zRLInkA8cIWWAK+cai8CxmhpO3
> jYiv6j8NmnVOjKlu4XDflOg3jL5D1DCO6QlgQRtlY6uh7Psym7Y=
> =KCBo
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Fwd: tomcat automatically binds it to 0.0.0.0 from 127.0.0.1

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rakesh,

On 6/19/17 12:43 AM, Rakesh Java wrote:
> Below is my netstat showing port bindings tcp 0 0 0.0.0.0:1234
> 0.0.0.0:* LISTEN

That doesn't show the pid or binary bound to port 1234.

With this configuration:



I get a socket bound to 127.0.0.1:8216:

> tcp6   0  0 127.0.0.1:8217  :::*   LISTEN
> 8183/java

... but when I use this:



> tcp6   0  0 :::8217 :::*   LISTEN
> 20591/java

Environment:
Tomcat 8.5.15
Oracle Java 1.8.0_101 (most important factor)
Linux kernel 2.6.32

I'm not sure why it's not working for you. The Tomcat version
shouldn't matter very much, since everything goes down to the JVM.

- -chris

> On Fri, Jun 16, 2017 at 9:55 PM, Christopher Schultz < 
> ch...@christopherschultz.net> wrote:
> 
> Rakesh,
> 
> On 6/16/17 5:48 AM, Rakesh Java wrote:
 I have made a port( example 1234) to be bound to the local
 host 127.0.0.1 .But when i restart tomcat automatically binds
 it to 0.0.0.0 .
 
 
 And my connector in server.xml contains 127.0.0.1 as address
 .
 
 >>> address="127.0.0.1" protocol="HTTP ...>
 
 My Tomcat Version
 
 Server version: Apache Tomcat/6.0.48 Server built:   Dec 12
 2016 14:06:06 UTC Server number:  6.0.48.0 OS Name:
 Linux JVM Version:1.8.0_111-b15 JVM Vendor: Oracle
 Corporation
 
 
 
 Logs in Tomcat
 
 May 03, 2017 1:58:19 PM
 org.apache.coyote.http11.Http11AprProtocol destroy INFO:
 Stopping Coyote HTTP/1.1 on http-127.0.0.1-1234 ...
 ... May 03, 2017 1:58:49 PM 
 org.apache.coyote.http11.Http11AprProtocol init INFO:
 Initializing Coyote HTTP/1.1 on http-0.0.0.0-1234
 
 Can some one say why this issue is happening ? Best Regards,
 Rakesh :-)
> 
> Please show the netstat showing your port bindings.
> 
> -chris
>> 
>> -
>>
>> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 
>> 
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAllJI8oACgkQHPApP6U8
pFgLwQ/9H1GT8TKCfrQtyiDJTxYqzEv6u6O/ZFvub1pqgFGuzPN61qUD+QB8Kl2R
iTM3VoxTYqlH15ZgSV5Roms6l6O9Hw6yZnFG9ooIp7Aerbc7uFJq6y57hmDVf3hd
t8661gYajju4Z00WJ7y7o6SGTWVox6PUz6yyBHKSOpPmGJkN0Nauxiumh2dk9Mcv
xPVAmVyzmIwiU8lb4EehCuYRBhviNxC9YvXjlBQ8sf8lswpEq7D6uH++Ye3LfgW9
GecW0POSU3CpJM5bk6Rm/Dm9f3UBR9VgnGRxb9v5YGJE2JKZ7/n7p0yHr24I81RE
rTGmA6AThP/nndCFKkc4tOFxDTTNSqXdSCyVrYP21Mgd/Ezx+vZNIN1hDJk3nMlM
S3e95zQHfaZtrfXscSkBhRKq5bUMxK367vv+t649UWlfk+kY1cp93NIWxaTTES1q
7BU2bl67E0hfTj9XtKcFlUJ9e5BCpB8KXXUai1h9/ZCPW9fGdaOrVIhTrC6cPYPW
965dxjA+8i+O9suzLSVk/6R185WpKuiRSCsJdRwZt+4buS/8mQ/GmNJwa3mWBRgY
CNBY9JocEagXvMw1j0VGghcs6pJYd3DISur9Q+zRLInkA8cIWWAK+cai8CxmhpO3
jYiv6j8NmnVOjKlu4XDflOg3jL5D1DCO6QlgQRtlY6uh7Psym7Y=
=KCBo
-END PGP SIGNATURE-

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

Re: Fwd: tomcat automatically binds it to 0.0.0.0 from 127.0.0.1

[Rakesh Java]

Hi Chris,

Below is my netstat showing port bindings
tcp 0 0 0.0.0.0:1234 0.0.0.0:* LISTEN

On Fri, Jun 16, 2017 at 9:55 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Rakesh,
>
> On 6/16/17 5:48 AM, Rakesh Java wrote:
> > I have made a port( example 1234) to be bound to the local host
> > 127.0.0.1 .But when i restart tomcat automatically binds it to
> > 0.0.0.0 .
> >
> >
> > And my connector in server.xml contains 127.0.0.1 as address .
> >
> >  > address="127.0.0.1" protocol="HTTP ...>
> >
> > My Tomcat Version
> >
> > Server version: Apache Tomcat/6.0.48 Server built:   Dec 12 2016
> > 14:06:06 UTC Server number:  6.0.48.0 OS Name:Linux JVM
> > Version:1.8.0_111-b15 JVM Vendor: Oracle Corporation
> >
> >
> >
> > Logs in Tomcat
> >
> > May 03, 2017 1:58:19 PM org.apache.coyote.http11.Http11AprProtocol
> > destroy INFO: Stopping Coyote HTTP/1.1 on http-127.0.0.1-1234
> > ... ... May 03, 2017 1:58:49 PM
> > org.apache.coyote.http11.Http11AprProtocol init INFO: Initializing
> > Coyote HTTP/1.1 on http-0.0.0.0-1234
> >
> > Can some one say why this issue is happening ? Best Regards, Rakesh
> > :-)
>
> Please show the netstat showing your port bindings.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAllEBnMACgkQHPApP6U8
> pFhIVBAAudSGcWGtW1Dld625XlC+r3qnP+uis4xPlHrV5dOtADZ3ITNdVSmLAhEV
> bR6E/Hi5JhOBx3P5bjcZwSmvI1717eFVZIqBzQDncXaBQNRjcZ7oEQ4nFCA2f+Y/
> lXKxivugy6Rl+a5XcbY7eJQ7JcUD9rL7takxlrV3Va490P9CTOLZzcGnlt7aeWzS
> Wf73tln7xqLxY8II5e5CutbrzT0+HAej/ItZEE5tOZNcq9QADvVjJYuaO0hq1j5r
> mkNb9//EfehD0aGJBoZ47OP1UympkBuR/jJ86zaCWsUkvjovX922iw8VEr/8oZSG
> K2hvHHkJpu4ITliRA2iWzw5p9EYsx8orqqKEbfRsfWG5Fep9w4Y+bz7hvx6w+NUt
> yE21zBjrxh5nipBFwmopoYkHO8ZyH7hoCqNkOtpV2zCcngW4IJxS2nOCyQQKz/MM
> d48+vWbDi6xMrb79l+mpGookMSA3Eie+sxmvS5/pKHY2G1r+QtJzGoR3UemPzzVr
> gzbEJ/AKyYhNrpDObWw3GlNZGCXjsgnDnvRGnDmZXQ1Ajj+7kv0TUirltMzJnGUO
> iagg9AcoAWa5VXkAcZBIecn2CK/klDIPgcassq9cb5PoJwIA2rh9/iSSsvBuh6sQ
> ne/bWQxBbaQAjzqCjncijqvPziR7vW/soIray4e3fiix9pgC3Fs=
> =x5df
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Fwd: tomcat automatically binds it to 0.0.0.0 from 127.0.0.1

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rakesh,

On 6/16/17 5:48 AM, Rakesh Java wrote:
> I have made a port( example 1234) to be bound to the local host 
> 127.0.0.1 .But when i restart tomcat automatically binds it to
> 0.0.0.0 .
> 
> 
> And my connector in server.xml contains 127.0.0.1 as address .
> 
>  address="127.0.0.1" protocol="HTTP ...>
> 
> My Tomcat Version
> 
> Server version: Apache Tomcat/6.0.48 Server built:   Dec 12 2016
> 14:06:06 UTC Server number:  6.0.48.0 OS Name:Linux JVM
> Version:1.8.0_111-b15 JVM Vendor: Oracle Corporation
> 
> 
> 
> Logs in Tomcat
> 
> May 03, 2017 1:58:19 PM org.apache.coyote.http11.Http11AprProtocol
> destroy INFO: Stopping Coyote HTTP/1.1 on http-127.0.0.1-1234 
> ... ... May 03, 2017 1:58:49 PM
> org.apache.coyote.http11.Http11AprProtocol init INFO: Initializing
> Coyote HTTP/1.1 on http-0.0.0.0-1234
> 
> Can some one say why this issue is happening ? Best Regards, Rakesh
> :-)

Please show the netstat showing your port bindings.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAllEBnMACgkQHPApP6U8
pFhIVBAAudSGcWGtW1Dld625XlC+r3qnP+uis4xPlHrV5dOtADZ3ITNdVSmLAhEV
bR6E/Hi5JhOBx3P5bjcZwSmvI1717eFVZIqBzQDncXaBQNRjcZ7oEQ4nFCA2f+Y/
lXKxivugy6Rl+a5XcbY7eJQ7JcUD9rL7takxlrV3Va490P9CTOLZzcGnlt7aeWzS
Wf73tln7xqLxY8II5e5CutbrzT0+HAej/ItZEE5tOZNcq9QADvVjJYuaO0hq1j5r
mkNb9//EfehD0aGJBoZ47OP1UympkBuR/jJ86zaCWsUkvjovX922iw8VEr/8oZSG
K2hvHHkJpu4ITliRA2iWzw5p9EYsx8orqqKEbfRsfWG5Fep9w4Y+bz7hvx6w+NUt
yE21zBjrxh5nipBFwmopoYkHO8ZyH7hoCqNkOtpV2zCcngW4IJxS2nOCyQQKz/MM
d48+vWbDi6xMrb79l+mpGookMSA3Eie+sxmvS5/pKHY2G1r+QtJzGoR3UemPzzVr
gzbEJ/AKyYhNrpDObWw3GlNZGCXjsgnDnvRGnDmZXQ1Ajj+7kv0TUirltMzJnGUO
iagg9AcoAWa5VXkAcZBIecn2CK/klDIPgcassq9cb5PoJwIA2rh9/iSSsvBuh6sQ
ne/bWQxBbaQAjzqCjncijqvPziR7vW/soIray4e3fiix9pgC3Fs=
=x5df
-END PGP SIGNATURE-

-
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

[Mark Thomas]

On 01/05/17 20:24, Mohammed Manna wrote:
> Hi,
> 
> May be i didn't explain the issue clearly. I am using the same compiler as
> Tomcat (JDT compiler, not ANT).

Ant isn't a complier. It is a build tool. Ant uses javac (i.e.
tools.jar) to build with.

> When doing a standalone *ant build*, my
> pre-compilation doesn't show any 64k size error for __jspService(). But
> when I launch the application, it *does* throws error on 64k size on
> various pages.
> 
> Just for the sake of comparison, I did the following:
> 
> 1) Threw a purposefully generated error on ant build - captured to stack to
> see which compiler implementation it followings - JDT compiler

Show us the stack trace please.

> 2) Corrected the error above and passed the build
> 3) Deployed and launched the application.

Did you deploy the pre-compiled application?

> 4) Went to the problem page - generated the 64k error to capture the stack
> information.
> 5) The compiler implementation is the same as reported on Ant Build error
> (JDTCompiler).

If javac can compile the page without error then you should either:
a) use those pre-compiled pages
b) configure Tomcat to do on-the0fly compilation with javac.

> This is why I have been struggling to understand why the behaviour is so
> different when the compiler isn't ?

I'm not convinced you are using the compiler you think you are.

> Is there any tuning of <*javac> *task definition in ant build I can use?
> What do you recommend?

Answer the above questions.

Provide a simple as possible JSP (probably one that uses a single tag
repeatedly) that demonstrates the problem.

Mark


> 
> KR,
> 
> from the JspCompilationContext, what I can see is that it will use JDT
> compiler when nothing is specified and the compilation will be based on 1.7
> standard. Which means my *ant build* will also use JDT compiler
> (org.apache.jasper.compiler.JDTCompiler). This is why I have been
> struggling to understand why this is so different if
> On 30 Apr 2017 12:05, "Mark Thomas"  wrote:
> 
> 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 i

Re: Fwd: Identifying 64k size violation for __jspService methods loaded by Tomcat

[Mohammed Manna]

Hi,

May be i didn't explain the issue clearly. I am using the same compiler as
Tomcat (JDT compiler, not ANT). When doing a standalone *ant build*, my
pre-compilation doesn't show any 64k size error for __jspService(). But
when I launch the application, it *does* throws error on 64k size on
various pages.

Just for the sake of comparison, I did the following:

1) Threw a purposefully generated error on ant build - captured to stack to
see which compiler implementation it followings - JDT compiler
2) Corrected the error above and passed the build
3) Deployed and launched the application.
4) Went to the problem page - generated the 64k error to capture the stack
information.
5) The compiler implementation is the same as reported on Ant Build error
(JDTCompiler).

This is why I have been struggling to understand why the behaviour is so
different when the compiler isn't ?

Is there any tuning of <*javac> *task definition in ant build I can use?
What do you recommend?

KR,

from the JspCompilationContext, what I can see is that it will use JDT
compiler when nothing is specified and the compilation will be based on 1.7
standard. Which means my *ant build* will also use JDT compiler
(org.apache.jasper.compiler.JDTCompiler). This is why I have been
struggling to understand why this is so different if
On 30 Apr 2017 12:05, "Mark Thomas"  wrote:

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 intu

Re: Fwd: Identifying 64k size violation for __jspService methods loaded by Tomcat

[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 of your JSP
 methods include:
>>>

Re: Fwd: Identifying 64k size violation for __jspService methods loaded by Tomcat

[Mohammed Manna]

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.







































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:
> >>
> >> trimSpaces - true
> >> enablePooling - false
> >>
> >> Note the disabling pooling may impact performance. It depends on lot on
> >> the complexity of the tags.
> >>
> >>> 1) How can I identify my JSP pages which are going to have this issue?
> >>> 2) I have tried using ANT build and compiled my JSPs. It simply passes
> >> the
> >>> build, but doesn't report any method size violation. Do you have any
> >>> development mode support that can expose these affected methods.
> >>
> >> Do those pre-compiled JSPs then execute without error?
> >>
> >> Pre-compilation typically uses javac whereas on the fly compilation
> >> typically uses JDT (the Eclipse Compiler). It is possible that
> >> differences in the compilers means that a class compiles with one but
> >

Re: Fwd: Identifying 64k size violation for __jspService methods loaded by Tomcat

[Mark Thomas]

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:
>>
>> trimSpaces - true
>> enablePooling - false
>>
>> Note the disabling pooling may impact performance. It depends on lot on
>> the complexity of the tags.
>>
>>> 1) How can I identify my JSP pages which are going to have this issue?
>>> 2) I have tried using ANT build and compiled my JSPs. It simply passes
>> the
>>> build, but doesn't report any method size violation. Do you have any
>>> development mode support that can expose these affected methods.
>>
>> Do those pre-compiled JSPs then execute without error?
>>
>> Pre-compilation typically uses javac whereas on the fly compilation
>> typically uses JDT (the Eclipse Compiler). It is possible that
>> differences in the compilers means that a class compiles with one but
>> fails with the other - particularly if your code is close to the boundary.
>>
>> It is possible to configure Jasper to compile JSPs with Ant and javac
>> (see the compiler init parameter).
>>
>> I suggest you try the recommendations above and see how you get on.
>>
>>> I appreciate that these are too specific questions, but Tomcat 8.0.39
>>> upgrade clearly didn't consider legacy systems and has left a massive
>>> refactoring job to the developers. So, it would be great if you could
>>> proactively extend "Known Issues" section with these.
>>
>> Patches welcome.
>>
>> Mark
>>
>>
>> [1] http://tomcat.markmail.org/thread/6jz7wfpcse6oxdgd
>>
>>
>> -
>> 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: Fwd: Identifying 64k size violation for __jspService methods loaded by Tomcat

[Mohammed Manna]

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?


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:
>
> trimSpaces - true
> enablePooling - false
>
> Note the disabling pooling may impact performance. It depends on lot on
> the complexity of the tags.
>
> > 1) How can I identify my JSP pages which are going to have this issue?
> > 2) I have tried using ANT build and compiled my JSPs. It simply passes
> the
> > build, but doesn't report any method size violation. Do you have any
> > development mode support that can expose these affected methods.
>
> Do those pre-compiled JSPs then execute without error?
>
> Pre-compilation typically uses javac whereas on the fly compilation
> typically uses JDT (the Eclipse Compiler). It is possible that
> differences in the compilers means that a class compiles with one but
> fails with the other - particularly if your code is close to the boundary.
>
> It is possible to configure Jasper to compile JSPs with Ant and javac
> (see the compiler init parameter).
>
> I suggest you try the recommendations above and see how you get on.
>
> > I appreciate that these are too specific questions, but Tomcat 8.0.39
> > upgrade clearly didn't consider legacy systems and has left a massive
> > refactoring job to the developers. So, it would be great if you could
> > proactively extend "Known Issues" section with these.
>
> Patches welcome.
>
> Mark
>
>
> [1] http://tomcat.markmail.org/thread/6jz7wfpcse6oxdgd
>
>
> -
> 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

[Mark Thomas]

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:

trimSpaces - true
enablePooling - false

Note the disabling pooling may impact performance. It depends on lot on
the complexity of the tags.

> 1) How can I identify my JSP pages which are going to have this issue?
> 2) I have tried using ANT build and compiled my JSPs. It simply passes the
> build, but doesn't report any method size violation. Do you have any
> development mode support that can expose these affected methods.

Do those pre-compiled JSPs then execute without error?

Pre-compilation typically uses javac whereas on the fly compilation
typically uses JDT (the Eclipse Compiler). It is possible that
differences in the compilers means that a class compiles with one but
fails with the other - particularly if your code is close to the boundary.

It is possible to configure Jasper to compile JSPs with Ant and javac
(see the compiler init parameter).

I suggest you try the recommendations above and see how you get on.

> I appreciate that these are too specific questions, but Tomcat 8.0.39
> upgrade clearly didn't consider legacy systems and has left a massive
> refactoring job to the developers. So, it would be great if you could
> proactively extend "Known Issues" section with these.

Patches welcome.

Mark


[1] http://tomcat.markmail.org/thread/6jz7wfpcse6oxdgd


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

Re: Fwd: Custom JNDIRealm with Configuration

[Felix Schumacher]

Am 13.04.2017 um 12:58 schrieb Lucas S. Silva:

Hi All,

I am implementing a custom JNDIRealm and I need to pass some
configurations to it.

I tried to pass the configuration via Real configuration



and in my code I define the setter and getter for
*configurationPattern* but when I debug it doesn't seems to
be set? I also need to add more parameters that may
not fit Realm.
Can I access Tomcat configuration from code?
Are you sure, that you are editing the correct file? What happens, when 
you add a log statement in your constructor?


And by the way, the debug parameter is not used anymore.

Regards,
 Felix



Thanks for the help in advance.

Cheers,
Lucas




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

Re: Fwd: Failed to stop component [StandardEngine[Catalina].StandardHost[localhost]

[Mark Thomas]

On 29 December 2016 09:56:45 GMT+00:00, Fady Haikal  
wrote:
>Dear Mark,
>is this bug is fixed in any version?

It hasn't been fixed yet but assuming we follow the usual pattern, it will be 
fixed for the next set of Tomcat releases in early January.

Mark


>Regards,
>Fady
>
>On Thu, Dec 22, 2016 at 10:22 PM, Mark Thomas  wrote:
>> On 22/12/2016 15:46, Fady Haikal wrote:
>>> We can see the below error on the log file please advise:
>>
>> You are using multiple start/start threads and the RMI reference
>> cleaning isn't thread safe. Arguably that is a bug in Tomcat but if
>you
>> fix the RMI memory leaks in your application you won't hit the Tomcat
>bug.
>>
>> Mark
>>
>>
>>>
>>> OS: windows
>>> Tomcat Version: 8.0.30
>>> Cluster Tomcat
>>>
>>> 30-Nov-2016 08:32:21.197 SEVERE [Catalina-startStop-2]
>>> org.apache.catalina.core.ContainerBase.stopInternal A child
>container
>>> failed during stop
>>>
>>> java.util.concurrent.ExecutionException:
>>> org.apache.catalina.LifecycleException: Failed to stop component
>>> [StandardEngine[Catalina].StandardHost[localhost].StandardContext[]]
>>>
>>> at java.util.concurrent.FutureTask.report(Unknown
>Source)
>>>
>>> at java.util.concurrent.FutureTask.get(Unknown
>Source)
>>>
>>> at
>>>
>org.apache.catalina.core.ContainerBase.stopInternal(ContainerBase.java:972)
>>>
>>> at
>>> org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232)
>>>
>>> at
>>> org.apache.catalina.core.ContainerBase$StopChild.call(
>>> ContainerBase.java:1424)
>>>
>>> at
>>> org.apache.catalina.core.ContainerBase$StopChild.call(
>>> ContainerBase.java:1413)
>>>
>>> at java.util.concurrent.FutureTask.run(Unknown
>Source)
>>>
>>> at
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
>>>
>>> at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
>>>
>>> at java.lang.Thread.run(Unknown Source)
>>>
>>> Caused by: org.apache.catalina.LifecycleException: Failed to stop
>>> component [StandardEngine[Catalina].StandardHost[localhost].
>>> StandardContext[]]
>>>
>>> at
>>> org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:236)
>>>
>>> ... 6 more
>>>
>>> Caused by: org.apache.catalina.LifecycleException: Failed to stop
>>> component [WebappLoader[]]
>>>
>>> at
>>> org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:236)
>>>
>>> at
>>> org.apache.catalina.core.StandardContext.stopInternal(
>>> StandardContext.java:5517)
>>>
>>> at
>>> org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232)
>>>
>>> ... 6 more
>>>
>>> Caused by: java.util.ConcurrentModificationException
>>>
>>> at java.util.HashMap$HashIterator.nextEntry(Unknown
>Source)
>>>
>>> at java.util.HashMap$ValueIterator.next(Unknown
>Source)
>>>
>>> at
>>>
>org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesRmiTargets(
>>> WebappClassLoaderBase.java:2275)
>>>
>>> at
>>> org.apache.catalina.loader.WebappClassLoaderBase.clearReferences(
>>> WebappClassLoaderBase.java:1578)
>>>
>>> at
>>> org.apache.catalina.loader.WebappClassLoaderBase.stop(
>>> WebappClassLoaderBase.java:1521)
>>>
>>> at
>>>
>org.apache.catalina.loader.WebappLoader.stopInternal(WebappLoader.java:447)
>>>
>>> at
>>> org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232)
>>>
>>> ... 8 more
>>>
>>>
>>>
>>>
>>> 30-Nov-2016 08:32:21.354 SEVERE [Catalina-startStop-2]
>>> org.apache.catalina.core.ContainerBase.stopInternal A child
>container
>>> failed during stop
>>>  java.util.concurrent.ExecutionException:
>>> org.apache.catalina.LifecycleException: Failed to stop component
>>>
>[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/docs]]
>>> at java.util.concurrent.FutureTask.report(Unknown Source)
>>> at java.util.concurrent.FutureTask.get(Unknown Source)
>>> at org.apache.catalina.core.ContainerBase.stopInternal(
>>> ContainerBase.java:972)
>>> at
>org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232)
>>> at org.apache.catalina.core.ContainerBase$StopChild.call(
>>> ContainerBase.java:1424)
>>> at org.apache.catalina.core.ContainerBase$StopChild.call(
>>> ContainerBase.java:1413)
>>> at java.util.concurrent.FutureTask.run(Unknown Source)
>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
>Source)
>>> at java.lang.Thread.run(Unknown Source)
>>> Caused by: org.apache.catalina.LifecycleException: Failed to stop
>>> component [StandardEngine[Catalina].StandardHost[localhost].
>>> StandardContext[/docs]]
>>> at
>org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:236)
>>> ... 6 more
>

Re: Fwd: Failed to stop component [StandardEngine[Catalina].StandardHost[localhost]

[Fady Haikal]

Dear Mark,
is this bug is fixed in any version?

Regards,
Fady

On Thu, Dec 22, 2016 at 10:22 PM, Mark Thomas  wrote:
> On 22/12/2016 15:46, Fady Haikal wrote:
>> We can see the below error on the log file please advise:
>
> You are using multiple start/start threads and the RMI reference
> cleaning isn't thread safe. Arguably that is a bug in Tomcat but if you
> fix the RMI memory leaks in your application you won't hit the Tomcat bug.
>
> Mark
>
>
>>
>> OS: windows
>> Tomcat Version: 8.0.30
>> Cluster Tomcat
>>
>> 30-Nov-2016 08:32:21.197 SEVERE [Catalina-startStop-2]
>> org.apache.catalina.core.ContainerBase.stopInternal A child container
>> failed during stop
>>
>> java.util.concurrent.ExecutionException:
>> org.apache.catalina.LifecycleException: Failed to stop component
>> [StandardEngine[Catalina].StandardHost[localhost].StandardContext[]]
>>
>> at java.util.concurrent.FutureTask.report(Unknown Source)
>>
>> at java.util.concurrent.FutureTask.get(Unknown Source)
>>
>> at
>> org.apache.catalina.core.ContainerBase.stopInternal(ContainerBase.java:972)
>>
>> at
>> org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232)
>>
>> at
>> org.apache.catalina.core.ContainerBase$StopChild.call(
>> ContainerBase.java:1424)
>>
>> at
>> org.apache.catalina.core.ContainerBase$StopChild.call(
>> ContainerBase.java:1413)
>>
>> at java.util.concurrent.FutureTask.run(Unknown Source)
>>
>> at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
>>
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
>>
>> at java.lang.Thread.run(Unknown Source)
>>
>> Caused by: org.apache.catalina.LifecycleException: Failed to stop
>> component [StandardEngine[Catalina].StandardHost[localhost].
>> StandardContext[]]
>>
>> at
>> org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:236)
>>
>> ... 6 more
>>
>> Caused by: org.apache.catalina.LifecycleException: Failed to stop
>> component [WebappLoader[]]
>>
>> at
>> org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:236)
>>
>> at
>> org.apache.catalina.core.StandardContext.stopInternal(
>> StandardContext.java:5517)
>>
>> at
>> org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232)
>>
>> ... 6 more
>>
>> Caused by: java.util.ConcurrentModificationException
>>
>> at java.util.HashMap$HashIterator.nextEntry(Unknown Source)
>>
>> at java.util.HashMap$ValueIterator.next(Unknown Source)
>>
>> at
>> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesRmiTargets(
>> WebappClassLoaderBase.java:2275)
>>
>> at
>> org.apache.catalina.loader.WebappClassLoaderBase.clearReferences(
>> WebappClassLoaderBase.java:1578)
>>
>> at
>> org.apache.catalina.loader.WebappClassLoaderBase.stop(
>> WebappClassLoaderBase.java:1521)
>>
>> at
>> org.apache.catalina.loader.WebappLoader.stopInternal(WebappLoader.java:447)
>>
>> at
>> org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232)
>>
>> ... 8 more
>>
>>
>>
>>
>> 30-Nov-2016 08:32:21.354 SEVERE [Catalina-startStop-2]
>> org.apache.catalina.core.ContainerBase.stopInternal A child container
>> failed during stop
>>  java.util.concurrent.ExecutionException:
>> org.apache.catalina.LifecycleException: Failed to stop component
>> [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/docs]]
>> at java.util.concurrent.FutureTask.report(Unknown Source)
>> at java.util.concurrent.FutureTask.get(Unknown Source)
>> at org.apache.catalina.core.ContainerBase.stopInternal(
>> ContainerBase.java:972)
>> at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232)
>> at org.apache.catalina.core.ContainerBase$StopChild.call(
>> ContainerBase.java:1424)
>> at org.apache.catalina.core.ContainerBase$StopChild.call(
>> ContainerBase.java:1413)
>> at java.util.concurrent.FutureTask.run(Unknown Source)
>> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
>> at java.lang.Thread.run(Unknown Source)
>> Caused by: org.apache.catalina.LifecycleException: Failed to stop
>> component [StandardEngine[Catalina].StandardHost[localhost].
>> StandardContext[/docs]]
>> at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:236)
>> ... 6 more
>> Caused by: org.apache.catalina.LifecycleException: Failed to stop
>> component [WebappLoader[/docs]]
>> at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:236)
>> at org.apache.catalina.core.StandardContext.stopInternal(
>> StandardContext.java:5517)
>> at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232)
>> ... 6 more
>>

Re: Fwd: Failed to stop component [StandardEngine[Catalina].StandardHost[localhost]

[Mark Thomas]

On 22/12/2016 15:46, Fady Haikal wrote:
> We can see the below error on the log file please advise:

You are using multiple start/start threads and the RMI reference
cleaning isn't thread safe. Arguably that is a bug in Tomcat but if you
fix the RMI memory leaks in your application you won't hit the Tomcat bug.

Mark


> 
> OS: windows
> Tomcat Version: 8.0.30
> Cluster Tomcat
> 
> 30-Nov-2016 08:32:21.197 SEVERE [Catalina-startStop-2]
> org.apache.catalina.core.ContainerBase.stopInternal A child container
> failed during stop
> 
> java.util.concurrent.ExecutionException:
> org.apache.catalina.LifecycleException: Failed to stop component
> [StandardEngine[Catalina].StandardHost[localhost].StandardContext[]]
> 
> at java.util.concurrent.FutureTask.report(Unknown Source)
> 
> at java.util.concurrent.FutureTask.get(Unknown Source)
> 
> at
> org.apache.catalina.core.ContainerBase.stopInternal(ContainerBase.java:972)
> 
> at
> org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232)
> 
> at
> org.apache.catalina.core.ContainerBase$StopChild.call(
> ContainerBase.java:1424)
> 
> at
> org.apache.catalina.core.ContainerBase$StopChild.call(
> ContainerBase.java:1413)
> 
> at java.util.concurrent.FutureTask.run(Unknown Source)
> 
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> 
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> 
> at java.lang.Thread.run(Unknown Source)
> 
> Caused by: org.apache.catalina.LifecycleException: Failed to stop
> component [StandardEngine[Catalina].StandardHost[localhost].
> StandardContext[]]
> 
> at
> org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:236)
> 
> ... 6 more
> 
> Caused by: org.apache.catalina.LifecycleException: Failed to stop
> component [WebappLoader[]]
> 
> at
> org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:236)
> 
> at
> org.apache.catalina.core.StandardContext.stopInternal(
> StandardContext.java:5517)
> 
> at
> org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232)
> 
> ... 6 more
> 
> Caused by: java.util.ConcurrentModificationException
> 
> at java.util.HashMap$HashIterator.nextEntry(Unknown Source)
> 
> at java.util.HashMap$ValueIterator.next(Unknown Source)
> 
> at
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesRmiTargets(
> WebappClassLoaderBase.java:2275)
> 
> at
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferences(
> WebappClassLoaderBase.java:1578)
> 
> at
> org.apache.catalina.loader.WebappClassLoaderBase.stop(
> WebappClassLoaderBase.java:1521)
> 
> at
> org.apache.catalina.loader.WebappLoader.stopInternal(WebappLoader.java:447)
> 
> at
> org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232)
> 
> ... 8 more
> 
> 
> 
> 
> 30-Nov-2016 08:32:21.354 SEVERE [Catalina-startStop-2]
> org.apache.catalina.core.ContainerBase.stopInternal A child container
> failed during stop
>  java.util.concurrent.ExecutionException:
> org.apache.catalina.LifecycleException: Failed to stop component
> [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/docs]]
> at java.util.concurrent.FutureTask.report(Unknown Source)
> at java.util.concurrent.FutureTask.get(Unknown Source)
> at org.apache.catalina.core.ContainerBase.stopInternal(
> ContainerBase.java:972)
> at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232)
> at org.apache.catalina.core.ContainerBase$StopChild.call(
> ContainerBase.java:1424)
> at org.apache.catalina.core.ContainerBase$StopChild.call(
> ContainerBase.java:1413)
> at java.util.concurrent.FutureTask.run(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> Caused by: org.apache.catalina.LifecycleException: Failed to stop
> component [StandardEngine[Catalina].StandardHost[localhost].
> StandardContext[/docs]]
> at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:236)
> ... 6 more
> Caused by: org.apache.catalina.LifecycleException: Failed to stop
> component [WebappLoader[/docs]]
> at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:236)
> at org.apache.catalina.core.StandardContext.stopInternal(
> StandardContext.java:5517)
> at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232)
> ... 6 more
> Caused by: java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextEntry(Unknown Source)
> at java.util.HashMap$ValueIterator.next(Unknown Source)
> at org.apache.catalina.loader.WebappClassLoaderBa

Re: Fwd: No longer able to use my own org.apache.catalina.authenticator.BasicAuthenticator in Tomcat 8.5.5

[Mark Thomas]

On 03/10/2016 14:20, Johannes Michler wrote:
> Hi Mark,
> 
> Thanks a lot for pointing out. Indeed I relied to much that I did not get
> any faults and didn't check that part. I'll try with the renamed method
> tomorrow, but I'm quite sure that will solve the issue.

Great.

> Regarding returning http 403 you suggest to do that in our custom
> basicauthenticator as well, correct? But this would still require us to
> install a tomcat version specific library globally, wouldn't it?

It would. I don't see a way to avoid this with custom code at this point.

Mark


> 
> Br
> Johannes
> 
> Am 03.10.2016 15:01 schrieb "Mark Thomas" :
> 
> On 01/10/2016 18:50, Johannes Michler wrote:
>> Hi,
>>
>> for our own web-application we overwrite the standard way of how Tomcat
>> BasicAuthenticator is working in order to avoid the popup of a
>> "Basic-Auth-Dialog" in some situations (where we're calling a service
>> provided by the tomcat over a script). Therefore our context.xml in the
>> app looks as follows:
>>
>> 
>> > className="biz.horus.database.server.servletscript.
> HorusTomcatBasicAuthenticator"
>> />
>> 
>>
>> HorusTomcatBasicAuthenticator is implemented as follows:
>> public class HorusTomcatBasicAuthenticator extends BasicAuthenticator
>> implements Authenticator {
>>
>> @Override
>> public boolean authenticate( Request request, HttpServletResponse
>> response) throws IOException {
>> System.out.println( " start out");
>> boolean result = super.authenticate( request, response);
>> System.out.println( " authenticate: " + result);
>> modifyResponse( request, response);
>> return result;
>> }
>> private void modifyResponse( Request request, HttpServletResponse
>> response) {
>> String url = request.getPathInfo();
>> System.out.println( "XX URL=" + url);
>> System.out.println( "XX Auth Header:" + response.getHeader(
>> AUTH_HEADER_NAME));
>> if ( response.getHeader( AUTH_HEADER_NAME) != null &&
>> url.startsWith( "/rest"))
>> response.setHeader( AUTH_HEADER_NAME, "HCP_BASIC");
>> }
>>
>> }
>>
>>
>> This is working great with Tomcat 8.0(.37). Though with Tomcat 8.5.5
>> that code in "authenticate" is no longer called. Instead it seams that
>> the "standard" BasicAuthenticator is being used.
>>
>> However if I entirely remove my jar-file that contains
>> HorusTomcatBasicAuthenticator.jar from the tomcat/lib-folder I'm getting
>> an error.
>>
>> Any ideas on that? I've looked into the tomcat 8.5 migration guide but
>> could not find any hints on changed behaviour.
> 
> 
> 
> Whilst the Tomcat 8.5 internal API is broadly compatible with Tomcat 8.0
> there have been many changes at the detail level and they are not binary
> compatible. Developers of custom components that interact with Tomcat's
> internals should review the JavaDoc for the relevant API.
> 
> 
> ->
> http://tomcat.apache.org/tomcat-8.5-doc/api/org/apache/
> catalina/authenticator/AuthenticatorBase.html
> 
> and
> 
> http://tomcat.apache.org/tomcat-8.5-doc/api/org/apache/
> catalina/authenticator/BasicAuthenticator.html
> 
> 
> Of particular note will be changes related to authenticate() and
> doAuthenticate().
> 
> 
>> Also when comparing the
>> Valve-Documentation of Tomcat 8.5 and 8.0 I do not see a difference.
>>
>> Or would it be better to address this with d...@tomcat.apache.org
>>  since it might as well be a bug?
> 
> No. The users list is the right place for this.
> 
>> Or is there a more elegant way to solve this problem to not reply with
>> "WWW-Authenticate: Basic" if authentication is not succesful?
> 
> Maybe just change the status code to 403?
> 
> Mark
> 
> 
> -
> 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: Fwd: No longer able to use my own org.apache.catalina.authenticator.BasicAuthenticator in Tomcat 8.5.5

[Johannes Michler]

Hi Mark,

Thanks a lot for pointing out. Indeed I relied to much that I did not get
any faults and didn't check that part. I'll try with the renamed method
tomorrow, but I'm quite sure that will solve the issue.

Regarding returning http 403 you suggest to do that in our custom
basicauthenticator as well, correct? But this would still require us to
install a tomcat version specific library globally, wouldn't it?

Br
Johannes

Am 03.10.2016 15:01 schrieb "Mark Thomas" :

On 01/10/2016 18:50, Johannes Michler wrote:
> Hi,
>
> for our own web-application we overwrite the standard way of how Tomcat
> BasicAuthenticator is working in order to avoid the popup of a
> "Basic-Auth-Dialog" in some situations (where we're calling a service
> provided by the tomcat over a script). Therefore our context.xml in the
> app looks as follows:
>
> 
>  className="biz.horus.database.server.servletscript.
HorusTomcatBasicAuthenticator"
> />
> 
>
> HorusTomcatBasicAuthenticator is implemented as follows:
> public class HorusTomcatBasicAuthenticator extends BasicAuthenticator
> implements Authenticator {
>
> @Override
> public boolean authenticate( Request request, HttpServletResponse
> response) throws IOException {
> System.out.println( " start out");
> boolean result = super.authenticate( request, response);
> System.out.println( " authenticate: " + result);
> modifyResponse( request, response);
> return result;
> }
> private void modifyResponse( Request request, HttpServletResponse
> response) {
> String url = request.getPathInfo();
> System.out.println( "XX URL=" + url);
> System.out.println( "XX Auth Header:" + response.getHeader(
> AUTH_HEADER_NAME));
> if ( response.getHeader( AUTH_HEADER_NAME) != null &&
> url.startsWith( "/rest"))
> response.setHeader( AUTH_HEADER_NAME, "HCP_BASIC");
> }
>
> }
>
>
> This is working great with Tomcat 8.0(.37). Though with Tomcat 8.5.5
> that code in "authenticate" is no longer called. Instead it seams that
> the "standard" BasicAuthenticator is being used.
>
> However if I entirely remove my jar-file that contains
> HorusTomcatBasicAuthenticator.jar from the tomcat/lib-folder I'm getting
> an error.
>
> Any ideas on that? I've looked into the tomcat 8.5 migration guide but
> could not find any hints on changed behaviour.



Whilst the Tomcat 8.5 internal API is broadly compatible with Tomcat 8.0
there have been many changes at the detail level and they are not binary
compatible. Developers of custom components that interact with Tomcat's
internals should review the JavaDoc for the relevant API.


->
http://tomcat.apache.org/tomcat-8.5-doc/api/org/apache/
catalina/authenticator/AuthenticatorBase.html

and

http://tomcat.apache.org/tomcat-8.5-doc/api/org/apache/
catalina/authenticator/BasicAuthenticator.html


Of particular note will be changes related to authenticate() and
doAuthenticate().


> Also when comparing the
> Valve-Documentation of Tomcat 8.5 and 8.0 I do not see a difference.
>
> Or would it be better to address this with d...@tomcat.apache.org
>  since it might as well be a bug?

No. The users list is the right place for this.

> Or is there a more elegant way to solve this problem to not reply with
> "WWW-Authenticate: Basic" if authentication is not succesful?

Maybe just change the status code to 403?

Mark


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

Re: Fwd: No longer able to use my own org.apache.catalina.authenticator.BasicAuthenticator in Tomcat 8.5.5

[Mark Thomas]

On 01/10/2016 18:50, Johannes Michler wrote:
> Hi,
> 
> for our own web-application we overwrite the standard way of how Tomcat
> BasicAuthenticator is working in order to avoid the popup of a
> "Basic-Auth-Dialog" in some situations (where we're calling a service
> provided by the tomcat over a script). Therefore our context.xml in the
> app looks as follows:
> 
> 
>  className="biz.horus.database.server.servletscript.HorusTomcatBasicAuthenticator"
> />
> 
> 
> HorusTomcatBasicAuthenticator is implemented as follows:
> public class HorusTomcatBasicAuthenticator extends BasicAuthenticator
> implements Authenticator {
> 
> @Override
> public boolean authenticate( Request request, HttpServletResponse
> response) throws IOException {
> System.out.println( " start out");
> boolean result = super.authenticate( request, response);
> System.out.println( " authenticate: " + result);
> modifyResponse( request, response);
> return result;
> }
> private void modifyResponse( Request request, HttpServletResponse
> response) {
> String url = request.getPathInfo();
> System.out.println( "XX URL=" + url);
> System.out.println( "XX Auth Header:" + response.getHeader(
> AUTH_HEADER_NAME));
> if ( response.getHeader( AUTH_HEADER_NAME) != null &&
> url.startsWith( "/rest"))
> response.setHeader( AUTH_HEADER_NAME, "HCP_BASIC");
> }
> 
> }
> 
> 
> This is working great with Tomcat 8.0(.37). Though with Tomcat 8.5.5
> that code in "authenticate" is no longer called. Instead it seams that
> the "standard" BasicAuthenticator is being used.
> 
> However if I entirely remove my jar-file that contains
> HorusTomcatBasicAuthenticator.jar from the tomcat/lib-folder I'm getting
> an error.
> 
> Any ideas on that? I've looked into the tomcat 8.5 migration guide but
> could not find any hints on changed behaviour.



Whilst the Tomcat 8.5 internal API is broadly compatible with Tomcat 8.0
there have been many changes at the detail level and they are not binary
compatible. Developers of custom components that interact with Tomcat's
internals should review the JavaDoc for the relevant API.


->
http://tomcat.apache.org/tomcat-8.5-doc/api/org/apache/catalina/authenticator/AuthenticatorBase.html

and

http://tomcat.apache.org/tomcat-8.5-doc/api/org/apache/catalina/authenticator/BasicAuthenticator.html


Of particular note will be changes related to authenticate() and
doAuthenticate().


> Also when comparing the
> Valve-Documentation of Tomcat 8.5 and 8.0 I do not see a difference.
> 
> Or would it be better to address this with d...@tomcat.apache.org
>  since it might as well be a bug?

No. The users list is the right place for this.

> Or is there a more elegant way to solve this problem to not reply with
> "WWW-Authenticate: Basic" if authentication is not succesful?

Maybe just change the status code to 403?

Mark


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

Re: Fwd: Compiling Tomcat Native 1.2.8

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Pierce,

On 9/12/16 4:32 PM, Pierce Allen wrote:
> I run a collection Tomcat web servers on Redhat 7.2 (up-to-date)
> 
> Normally we like to compile and use the latest stable version of
> Tomcat Native we can get our hands on (currently the one that ships
> with Tomcat 8.5.5.0 is labeled tcnative 1.2.8). However, when I try
> to compile recent versions of Tomcat Native I get an error that my
> OpenSSL version is too low:
> 
> checking OpenSSL library version >= 1.0.2... configure: error:
> Your version of O penSSL is not compatible with this version of
> tcnative
> 
> I don't really want to muck up the distro by trying to update
> OpenSSL by downloading and compiling OpenSSL's source code. RedHat
> backports security fixes to OpenSSL 1.0.1e so there are no
> "heartbleed" or other known vulnerabilities with the in-band
> OpenSSL version.  Is there some workaround or procedure that can be
> used to get recent versions of Tomcat Native to compile on up to
> date RedHat systems?

You can still run with a tcnative 1.1 against this older version of
OpenSSL. What version do you actually have?

You can also try to use "--disable-openssl-version-check" with
./configure to ignore the version check and hope for the best.
Officially, tcnative 1.2.x requires a minimum of OpenSSL 1.0.2

http://tomcat.apache.org/native-doc/miscellaneous/changelog.html

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

iQIcBAEBCAAGBQJX2ci5AAoJEBzwKT+lPKRYhO4QALNlQJt2jUCIi/nvzSBXeJfP
UG7Ui7gDsuep8GhXVNftb9rY6CXqF66va4lhJUbE2CmNBsyZuLzH8PYxZNthS9IB
em4rLPA9rCKlx+JpZkvSSqNIO4cn9NO8jiZJrBVQRHomvOTkFC6SWI4Dhgoz5xtE
U1PSp2LYpDfgI6ugxPUFc44G4WLOXVzmXlo3i7I9CSfD/BwQQl1xUOkExRXObTDH
va5/uzMqBCFSVo+aUXt6af89ja6hNYHY66wS1wLlspCGWD3Y4MPa3eXy83TUc2ph
F06Y47ShCJPnRI0ssGFNHKSltPLgsYTUzepTQ39517Sn4Svk5Wnk3jD9C18NN7mW
+BRuiIOwScxM2Z8V1LsvaxTtFNE+xP3443CvN08CzDE1+qt1zas6iJXU7ZcIfQFC
5VwQWTfojsxrr6l1/jSBw8qZjc6nFwqDiNsnDpJl0rki39yxTQi6WXl761C49GRZ
2b2lb9j4YPDKr4ia5mnJFY7zGA0Tk9QBZXZvk/P4/qeeZ0o01xjhqOUvz6o9GUfs
Q08Rs6aJyUtvZq75TuY+377Psglrq/IiyldGs3r8f5R2xrL/VxEOPdQXKCEvm8dU
yenLlAGMwfHdEhh8LLgxfhNJtYjjtLLGUjlvvSUT0b0OJl/UO6Xwc4h2tCImZXLs
gKhKu89iXpLMDphJEoCB
=WXCg
-END PGP SIGNATURE-

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

Re: Fwd: Compiling Tomcat Native 1.2.8

[l.pe...@senat.fr]

On 12/09/2016 22:32, Pierce Allen wrote:


Hello -

I run a collection Tomcat web servers on Redhat 7.2 (up-to-date)

Normally we like to compile and use the latest stable version of 
Tomcat Native we can get our hands on (currently the one that ships 
with Tomcat 8.5.5.0 is labeled tcnative 1.2.8). However, when I try to 
compile recent versions of Tomcat Native I get an error that my 
OpenSSL version is too low:


checking OpenSSL library version >= 1.0.2... configure: error: Your 
version of O penSSL is not compatible with this version of tcnative


I don't really want to muck up the distro by trying to update OpenSSL 
by downloading and compiling OpenSSL's source code. RedHat backports 
security fixes to OpenSSL 1.0.1e so there are no "heartbleed" or other 
known vulnerabilities with the in-band OpenSSL version.  Is there some 
workaround or procedure that can be used to get recent versions of 
Tomcat Native to compile on up to date RedHat systems?

In a similar situation, I statically link openssl.

Please find enclosed my .spec for Tomcat 8.5.5.
I tried not to alter it too much when removing information specific to 
my organisation.


Ludovic

|
| AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
|

%define major_version 8
%define minor_version 5
%define revision 5
%define full_version %{major_version}.%{minor_version}.%{revision}

%define native_major_version 1
%define native_minor_version 2
%define native_revision 8
%define native_full_version %{native_major_version}.%{native_minor_version}.%{native_revision}

%define commons_daemon_version 1.0.15

%define openssl_major 1
%define openssl_minor 0
%define openssl_revision 2h
%define openssl_full_version %{openssl_major}.%{openssl_minor}.%{openssl_revision}

%define apr_major 1
%define apr_minor 5
%define apr_revision 2
%define apr_full_version %{apr_major}.%{apr_minor}.%{apr_revision}

Name: my-tomcat
Version: %{full_version}
Release: 1
Summary: My Own Tomcat
License: My License
Group: my.group
autoprov: yes
autoreq: yes
Requires: my-jre
BuildRoot: %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XX)
# dependance vers le jdk 7 par facilite (le 8 serait mieux)
BuildRequires: apr-devel openssl-devel java-1.7.0-openjdk, java-1.7.0-openjdk-devel, chrpath

%define source_file http://mirrors.ircam.fr/pub/apache/tomcat/tomcat-%{major_version}/v%{full_version}/bin/apache-tomcat-%{full_version}.tar.gz
%define openssl_file https://www.openssl.org/source/openssl-%{openssl_major}.%{openssl_minor}.%{openssl_revision}.tar.gz
%define apr_file http://wwwftp.ciril.fr/pub/apache/apr/apr-%{apr_major}.%{apr_minor}.%{apr_revision}.tar.bz2

Source: %{source_file}
Source1: mysql-connector-java-5.1.23-bin.jar
Source2: OracleDriver-7.jar
Source3: postgresql-9.4.1209.jar
Source6: %{openssl_file}
Source7: %{apr_file}

Patch: manager.patch
Patch1: server.xml.patch
Patch2: tomcat-users.xml.patch

# FHS 2.3 compliant tree structure - http://www.pathname.com/fhs/2.3/
%define basedir %{_var}/lib/%{name}
%define appdir %{basedir}/webapps
%define bindir %{_datadir}/%{name}/bin
%define confdir %{_sysconfdir}/%{name}
%define homedir %{_datadir}/%{name}
%define libdir %{_javadir}/%{name}
%define logdir %{_var}/log/%{name}
%define cachedir %{_var}/cache/%{name}
%define tempdir %{cachedir}/temp
%define workdir %{cachedir}/work
%define _initrddir %{_sysconfdir}/init.d

%define tomcat_base %{homedir}


%description
My desc

Startup and shutdown are managed with commons-daemon %{commons_daemon_version}.


%prep
%{__mkdir} -p $RPM_BUILD_DIR/%{name}
cat << \EOF > %{_builddir}/%{name}/%{name}-req
#!/bin/sh
%{__find_requires} $* |\
  sed -e '/libcrypto/d' -e '/libssl.so/d' -e '/pkgconfig'
EOF

%define __find_requires %{_builddir}/%{name}/%{name}-req
chmod +x %{__find_requires}

%define _use_internal_dependency_generator 0

%setup -T -D -a 6 -n .
%setup -T -D -a 7 -n .
%setup -T -D -a 0 -n .

%patch -p0
%patch1 -p0
%patch2 -p0

cd ${RPM_BUILD_DIR}
tar xvzf apache-tomcat-%{full_version}/bin/tomcat-native.tar.gz
tar xvzf apache-tomcat-%{full_version}/bin/commons-daemon-native.tar.gz
if [ ! -d ${RPM_BUILD_DIR}/openssl-%{openssl_major}.%{openssl_minor}.%{openssl_revision} ]; then
   mv  ${RPM_BUILD_DIR}/openssl-* ${RPM_BUILD_DIR}/openssl-%{openssl_major}.%{openssl_minor}.%{openssl_revision}
fi

%build
%{__rm} -rf $RPM_BUILD_ROOT

pushd .
cd ${RPM_BUILD_DIR}/openssl-%{openssl_major}.%{openssl_minor}.%{openssl_revision}
./config --prefix=${RPM_BUILD_DIR}/openssl-inst no-shared -fPIC
make
make install_sw
popd
pushd .
cd ${RPM_BUILD_DIR}/apr-%{apr_major}.%{apr_minor}.%{apr_revision}
CFLAGS="-fPIC" ./configure --prefix=${RPM_BUILD_DIR}/apr-inst
make
make install
# lthis line desactivate dynamic linking against openssl
sed -i  -e "/dlname=/d" -e "/library_names=/d" ${RPM_BUILD_DIR}/apr-inst/lib/libapr-1.la
popd
pushd .
cd ${RPM_BUILD_DIR}/tomcat-native-%{native_full_version}-src/native
CFLAGS="-fPIC" ./configure --prefix=${RPM_BUILD_DIR}/tomcat-native-inst --with-apr=${RPM_BUILD_DIR}/apr-inst/bin/apr-

Re: Fwd: Fwd: EL Stream API differing from the Java one

[Mark Thomas]

On 24/08/2016 07:43, Aritz Maeztu wrote:
> I've already posted the issue in StackOverflow:
> http://stackoverflow.com/questions/39096941/does-tomcats-el-stream-api-make-sense
> 
> Using Tomcat 8.0.30, I've implemented some EL accesses to the stream
> API. However, I've found that this expression:
> 
> |#{testBean.values.stream().anyMatch(str ->str == 'Test1')} Returns a 
> ||org.apache.el.stream.Optional type. Looking at the API documentation it
> also says that.   However, in the standard Java Stream API this kind of
> method returns a boolean, which is the result of evaluating the
> Predicate and see if any object in the stream matches it.|

Yes, the EL 3.0 Stream API is not identical to the Java 8 Stream API.
This is because the EL 3.0 Stream API was finalized before the Java 8
API. As a result, there are some differences. This is one of them.

Mark


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

Re: Fwd: tomcat 8.0 session_id resets in AWS

[Mark Thomas]

On 29/06/2016 14:05, Gibu George wrote:
> Hi All,
> 
> I'm trying to get tomcat to work in a cluster with sessions being persisted
> in mysql, in AWS. I have setup two tomcat servers in the clusters using "
> org.apache.catalina.tribes.membership.StaticMember".
> 
> The problem that I am facing is that when a request that containing
> session_id created by tomcat instance1 is send to tomcat instance2, tomcat
> instance2 fails to validate the session_id ( created by instance1 ) and
> send a new session_id, created by instance2 in the response.
> 
> Why is this happening?

Many possible reasons. More investigation is required. Is your web
application cluster enabled? What do the logs tell you is happening with
the cluster?

> Has anyone face such an issue ?

Frequently.

> my tomcat is front ended by nginx
> 
> Part 2: How do I enable logging for session management in tomcat? What do i
> need to add in logging.properties file?

org.apache.catalina.session.level = FINE
org.apache.catalina.tribes.level = FINE

is probably overkill but you can narrow it down once you figure out what
is useful (or not) for your situation.

Mark

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

Re: Fwd: webservice deployment on tomcat 1.7 with JAVA 1.8 is giving deployment errors

[Konstantin Kolinko]

2016-05-10 17:34 GMT+03:00 Christopher Schultz :
>
> Looks like the real error is:
>
>> Caused by: java.util.ServiceConfigurationError:
>> javax.xml.validation.SchemaFactory:
>>
> jar:file:/C:/Program%20Files%20(x86)/Apache%20Software%20Foundation/Tomc
> at%208.0/webapps/My-Documentum-for-Microsoft-Outlook-WebService-7.3.0/WE
> B-INF/lib/xerces-impl.jar!/META-INF/services/javax.xml.validation.Schema
> Factory:1:
>> Illegal provider-class name: http\://
>>
> www.w3.org/2001/XMLSchema=com.sun.org.apache.xerces.internal.jaxp.valida
> tion.xs.SchemaFactoryImpl
>
> Find the place where you have that odd provider class name and change
> it to be a legitimate Java class. (Just a guess).
>
> - -chris


The class name 
"com.sun.org.apache.xerces.internal.jaxp.validation.xs.SchemaFactoryImpl"
 is odd. It looks like
internal copy of Apache Xerces library as was used by an (old) JRE.
It is as if someone is trying to bundle a JRE class within a web
application.

1. Redistributing JRE classes in such way is wrong.

2. You can get the real Xerces-J  XML parser library here:
http://xerces.apache.org/xerces2-j/
http://xerces.apache.org/mirrors.cgi

Best regards,
Konstantin Kolinko

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