Re: Intermittent error 404

[Mark Thomas]

8 Apr 2024 11:20:09 andreas.moro...@wobi.bz.it:


Hello
we use Apache Tomcat/8.5.99.


Tomcat 8.5.x is no longer supported by the Tomcat community. You should 
upgrade to at least 9.0.x or consider purchasing 8.5.x support from one 
of the commercial vendors that offer it.


It sounds like an issue with JSP compilation. I'd suggest stopping 
Tomcat, cleaning out the work directory and then starting Tomcat.


Mark



Last week I changed the user of the Tomcat services.


When I refresh teh page then every second time the page appears 
correctly and the other 50% I get the error


No I get intermittent error 404

The origin server did not find a current representation for the target 
resource or is not willing to disclose that one exists.


on the index.jsp

The user has the rights to read the index.jsp

The fact that sometimes it works and the next time it doesn't confuses 
me. If it were due to the rights, it should probably never work.

Can someone kindly help me?

Greetings
Andreas

Institut für den sozialen Wohnbau des Landes Südtirol
Istituto per l’edilizia sociale della Provincia autonoma di Bolzano
39100 Bozen Horazstraße 14 / 39100 Bolzano via Orazio, 14_*
*__*wobi.bz.it[https://www.wobi.bz.it/de/default.asp]*_*   
*_*ipes.bz.it[https://www.ipes.bz.it/it/default.asp]*_*



*[cid:_4_00C1B7780DBA0634003348A4C1258AF9]*

*
Dies ist eine vertrauliche Nachricht und nur für den Adressaten 
bestimmt. Sollten Sie diese Nachricht irrtümlich erhalten haben, bitten 
wir um Ihre diesbezügliche Benachrichtigung und um die Löschung der 
Nachricht. Eine Veröffentlichung oder Verbreitung des Inhaltes sowie 
jegliche anderweitige Verwendung sind untersagt.


Il contenuto di questa e-mail è rivolto esclusivamente al destinatario 
della stessa e deve intendersi riservato e personale. Laddove questa 
e-mail Le fosse pervenuta per errore, Le chiediamo di comunicarci 
l’errata notifica e di cancellarne il contenuto. Sono sempre vietate la 
pubblicazione o diffusione del contenuto, nonché l'utilizzo per 
qualsiasi altro scopo.


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

Intermittent error 404

[Andreas . Moroder]

Hello 
we use Apache Tomcat/8.5.99.
Last week I changed the user of the Tomcat services.


When I refresh teh page then every second time the page appears correctly 
and the other 50% I get the error

No I get intermittent error 404 

The origin server did not find a current representation for the target 
resource or is not willing to disclose that one exists.

on the index.jsp

The user has the rights to read the index.jsp

The fact that sometimes it works and the next time it doesn't confuses me. 
If it were due to the rights, it should probably never work. 
Can someone kindly help me?

Greetings
Andreas

Institut für den sozialen Wohnbau des Landes Südtirol
Istituto per l’edilizia sociale della Provincia autonoma di Bolzano
39100 Bozen Horazstraße 14 / 39100 Bolzano via Orazio, 14
wobi.bz.it   ipes.bz.it 





Dies ist eine vertrauliche Nachricht und nur für den Adressaten bestimmt. 
Sollten Sie diese Nachricht irrtümlich erhalten haben, bitten wir um Ihre 
diesbezügliche Benachrichtigung und um die Löschung der Nachricht. Eine 
Veröffentlichung oder Verbreitung des Inhaltes sowie jegliche anderweitige 
Verwendung sind untersagt.

Il contenuto di questa e-mail è rivolto esclusivamente al destinatario 
della stessa e deve intendersi riservato e personale. Laddove questa 
e-mail Le fosse pervenuta per errore, Le chiediamo di comunicarci l’errata 
notifica e di cancellarne il contenuto. Sono sempre vietate la 
pubblicazione o diffusione del contenuto, nonché l'utilizzo per qualsiasi 
altro scopo.

Re: [EXT]Re: 404 for j_security_check

[Christopher Schultz]

Rick,

On 3/19/24 12:58, Rick Noel wrote:

Thanks for the help, I agree with all your statements.

I now see the  JSESSIONID cookies.

I found a bug in my code. My issue was nothing to do with Tomcat behavior.


Sorry for you, but glad it wasn't us :)

-chris


-Original Message-
From: Christopher Schultz 
Sent: Sunday, March 17, 2024 10:57 AM
To: users@tomcat.apache.org
Subject: Re: [EXT]Re: 404 for j_security_check

[You don't often get email from ch...@christopherschultz.net. Learn why this is 
important at https://aka.ms/LearnAboutSenderIdentification ]

Rick,

On 3/15/24 13:49, Rick Noel wrote:


I really only want auth once

All hits to jsp pages after a successful login do not trigger the Auth process 
again.

But hits to java action class servlets do trigger the Auth process

Its  like session data is being lost for some pages but not for others


Can you watch the HTTP headers for your interaction to see what's happening? 
The browser should be sending JSESSIONID cookies with each request. If the 
server isn't sending any Set-Cookie header, the browser should leave things as 
they are.

Please note that Tomcat will send Set-Cookie when a session is created (by 
default, every JSP will create a session IIRC if you declare it to use 
sessions), plus Tomcat will rotate the session identifier as part of the 
authentication process. If you have code on the client that is storing the 
session and using it later, if your session id is being updated during 
authentication you need to make sure it gets updated everywhere the client is 
using it.


I was thinking maybe this is reason..

The Expires header specifies when content will expire, or how long content is 
"fresh."
After this time, the Portal Server will always check back with the remote 
server to see if the content has changed.
Most Web servers allow setting an absolute time to expire, a time
based on the last time that the client saw the object (last access time), or a 
time based on the last time the document changed on your server (last 
modification time).

In JSP, we can set caching to forever using the Expires header like so.

response.setDateHeader("Expires",Long.MAX_VALUE)

BUT I do not want to change my application code, I just want to tell
Tomcat 10 to stop Expiring cache so that session log in data is not
lost


No, the cache here refers to the client's resource (e.g. page, image,
etc.) cache. It has nothing to do with what's happening on the server.


My main question is
I want to know how to configure Tomcat 10 to not loose session data
that tells the user has successfully logged in


Are you properly encoding your URLs in your page like with 
HttpServletResponse.encodeURL()? If you are using cookie-based session-tracking 
it probably won't matter, but it's best practice to always do that to ensure 
your URLs are generated properly.

-chris


-Original Message-
From: Christopher Schultz 
Sent: Friday, March 15, 2024 12:19 PM
To: users@tomcat.apache.org
Subject: [EXT]Re: 404 for j_security_check

[You don't often get email from ch...@christopherschultz.net. Learn
why this is important at https://aka.ms/LearnAboutSenderIdentification
]

Rick,

On 3/14/24 15:37, Rick Noel wrote:

After moving from tomcat 9 to tomcat 10 after a user successfully
logs in and then hits a restricted page, the login page is hit again
but on this second login hit I get 404 page not found

This is actually expected, since j_security_check is only supposed to be used 
when the container (Tomcat) interrupts a user workflow to request 
authentication.


How do I set the correct path in my  login jsp so that
j_security_check is found?

BTW  I actually am wondering why a  successful logged on user would
even be sent to the log in page again?

That's more of a question for your application than anything else.


My login page  is ->   /membership/login.jsp

Here is how I set the path to  j_security_check in above login.jsp



My restricted  web.xml snippet


Are you doing what I call a "direct login" where you have a "login page"
that most users hit first. Like from example.com/app/ where there is no initial 
request for a protected resource? Or are your users always (1) requesting a 
protected resource then (2) Tomcat requests authentication then (3) the user is 
forwarded to the resource originally requested in (1)?




External
/external/*


radiovoodoo


NONE




Auth
/auth/*


radiovoodoo


NONE



FORM

/membership/login.jsp
/membership/error.jsp




Those NONE lines look weird to me. 
Why are you explicitly specifying those? What part of your configuration actually requests 
authentication and authorization?

-chris

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

CAUTION: This email originated from outside of the organization. Do 

RE: [EXT]Re: 404 for j_security_check

[Rick Noel]

Chris,

Thanks for the help, I agree with all your statements.

I now see the  JSESSIONID cookies.

I found a bug in my code. My issue was nothing to do with Tomcat behavior.

Rick Noel
Systems Programmer | Westwood One
rn...@westwoodone.com

-Original Message-
From: Christopher Schultz  
Sent: Sunday, March 17, 2024 10:57 AM
To: users@tomcat.apache.org
Subject: Re: [EXT]Re: 404 for j_security_check

[You don't often get email from ch...@christopherschultz.net. Learn why this is 
important at https://aka.ms/LearnAboutSenderIdentification ]

Rick,

On 3/15/24 13:49, Rick Noel wrote:
>
> I really only want auth once
>
> All hits to jsp pages after a successful login do not trigger the Auth 
> process again.
>
> But hits to java action class servlets do trigger the Auth process
>
> Its  like session data is being lost for some pages but not for others

Can you watch the HTTP headers for your interaction to see what's happening? 
The browser should be sending JSESSIONID cookies with each request. If the 
server isn't sending any Set-Cookie header, the browser should leave things as 
they are.

Please note that Tomcat will send Set-Cookie when a session is created (by 
default, every JSP will create a session IIRC if you declare it to use 
sessions), plus Tomcat will rotate the session identifier as part of the 
authentication process. If you have code on the client that is storing the 
session and using it later, if your session id is being updated during 
authentication you need to make sure it gets updated everywhere the client is 
using it.

> I was thinking maybe this is reason..
>
> The Expires header specifies when content will expire, or how long content is 
> "fresh."
> After this time, the Portal Server will always check back with the remote 
> server to see if the content has changed.
> Most Web servers allow setting an absolute time to expire, a time 
> based on the last time that the client saw the object (last access time), or 
> a time based on the last time the document changed on your server (last 
> modification time).
>
> In JSP, we can set caching to forever using the Expires header like 
> so.
>
> response.setDateHeader("Expires",Long.MAX_VALUE)
>
> BUT I do not want to change my application code, I just want to tell 
> Tomcat 10 to stop Expiring cache so that session log in data is not 
> lost

No, the cache here refers to the client's resource (e.g. page, image,
etc.) cache. It has nothing to do with what's happening on the server.

> My main question is
> I want to know how to configure Tomcat 10 to not loose session data 
> that tells the user has successfully logged in

Are you properly encoding your URLs in your page like with 
HttpServletResponse.encodeURL()? If you are using cookie-based session-tracking 
it probably won't matter, but it's best practice to always do that to ensure 
your URLs are generated properly.

-chris

> -Original Message-
> From: Christopher Schultz 
> Sent: Friday, March 15, 2024 12:19 PM
> To: users@tomcat.apache.org
> Subject: [EXT]Re: 404 for j_security_check
>
> [You don't often get email from ch...@christopherschultz.net. Learn 
> why this is important at https://aka.ms/LearnAboutSenderIdentification 
> ]
>
> Rick,
>
> On 3/14/24 15:37, Rick Noel wrote:
>> After moving from tomcat 9 to tomcat 10 after a user successfully 
>> logs in and then hits a restricted page, the login page is hit again 
>> but on this second login hit I get 404 page not found
> This is actually expected, since j_security_check is only supposed to be used 
> when the container (Tomcat) interrupts a user workflow to request 
> authentication.
>
>> How do I set the correct path in my  login jsp so that 
>> j_security_check is found?
>>
>> BTW  I actually am wondering why a  successful logged on user would 
>> even be sent to the log in page again?
> That's more of a question for your application than anything else.
>
>> My login page  is ->   /membership/login.jsp
>>
>> Here is how I set the path to  j_security_check in above login.jsp
>>
>> 
>>
>> My restricted  web.xml snippet
>
> Are you doing what I call a "direct login" where you have a "login page"
> that most users hit first. Like from example.com/app/ where there is no 
> initial request for a protected resource? Or are your users always (1) 
> requesting a protected resource then (2) Tomcat requests authentication then 
> (3) the user is forwarded to the resource originally requested in (1)?
>
>> 
>> 
>> External
>> /external/*
>> 
>> 
>> radiovoodoo
>&g

Re: [EXT]Re: 404 for j_security_check

[Christopher Schultz]

Rick,

On 3/15/24 13:49, Rick Noel wrote:


I really only want auth once

All hits to jsp pages after a successful login do not trigger the Auth process 
again.

But hits to java action class servlets do trigger the Auth process

Its  like session data is being lost for some pages but not for others


Can you watch the HTTP headers for your interaction to see what's 
happening? The browser should be sending JSESSIONID cookies with each 
request. If the server isn't sending any Set-Cookie header, the browser 
should leave things as they are.


Please note that Tomcat will send Set-Cookie when a session is created 
(by default, every JSP will create a session IIRC if you declare it to 
use sessions), plus Tomcat will rotate the session identifier as part of 
the authentication process. If you have code on the client that is 
storing the session and using it later, if your session id is being 
updated during authentication you need to make sure it gets updated 
everywhere the client is using it.



I was thinking maybe this is reason..

The Expires header specifies when content will expire, or how long content is 
"fresh."
After this time, the Portal Server will always check back with the remote 
server to see if the content has changed.
Most Web servers allow setting an absolute time to expire, a time based on the 
last time that the client saw the object (last access time),
or a time based on the last time the document changed on your server (last 
modification time).

In JSP, we can set caching to forever using the Expires header like so.

response.setDateHeader("Expires",Long.MAX_VALUE)

BUT I do not want to change my application code, I just want to tell Tomcat 10 
to stop
Expiring cache so that session log in data is not lost


No, the cache here refers to the client's resource (e.g. page, image, 
etc.) cache. It has nothing to do with what's happening on the server.



My main question is
I want to know how to configure Tomcat 10 to not loose session data that tells 
the user has successfully logged in


Are you properly encoding your URLs in your page like with 
HttpServletResponse.encodeURL()? If you are using cookie-based 
session-tracking it probably won't matter, but it's best practice to 
always do that to ensure your URLs are generated properly.


-chris


-Original Message-
From: Christopher Schultz 
Sent: Friday, March 15, 2024 12:19 PM
To: users@tomcat.apache.org
Subject: [EXT]Re: 404 for j_security_check

[You don't often get email from ch...@christopherschultz.net. Learn why this is 
important at https://aka.ms/LearnAboutSenderIdentification ]

Rick,

On 3/14/24 15:37, Rick Noel wrote:

After moving from tomcat 9 to tomcat 10 after a user successfully logs
in and then hits a restricted page, the login page is hit again but on
this second login hit I get 404 page not found

This is actually expected, since j_security_check is only supposed to be used 
when the container (Tomcat) interrupts a user workflow to request 
authentication.


How do I set the correct path in my  login jsp so that
j_security_check is found?

BTW  I actually am wondering why a  successful logged on user would
even be sent to the log in page again?

That's more of a question for your application than anything else.


My login page  is ->   /membership/login.jsp

Here is how I set the path to  j_security_check in above login.jsp



My restricted  web.xml snippet


Are you doing what I call a "direct login" where you have a "login page"
that most users hit first. Like from example.com/app/ where there is no initial 
request for a protected resource? Or are your users always (1) requesting a 
protected resource then (2) Tomcat requests authentication then (3) the user is 
forwarded to the resource originally requested in (1)?




External
/external/*


radiovoodoo


NONE




Auth
/auth/*


radiovoodoo


NONE



FORM

/membership/login.jsp
/membership/error.jsp




Those NONE lines look weird to me. 
Why are you explicitly specifying those? What part of your configuration actually requests 
authentication and authorization?

-chris

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

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you know the sender and you are sure the 
content is safe. Please report the message using the Report Message feature in 
your email client if you believe the email is suspicious.


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

RE: [EXT]Re: 404 for j_security_check

[Rick Noel]

I really only want auth once

All hits to jsp pages after a successful login do not trigger the Auth process 
again.

But hits to java action class servlets do trigger the Auth process

Its  like session data is being lost for some pages but not for others

I was thinking maybe this is reason..


The Expires header specifies when content will expire, or how long content is 
"fresh."
After this time, the Portal Server will always check back with the remote 
server to see if the content has changed.
Most Web servers allow setting an absolute time to expire, a time based on the 
last time that the client saw the object (last access time),
or a time based on the last time the document changed on your server (last 
modification time).

In JSP, we can set caching to forever using the Expires header like so.

response.setDateHeader("Expires",Long.MAX_VALUE)

BUT I do not want to change my application code, I just want to tell Tomcat 10 
to stop
Expiring cache so that session log in data is not lost

My main question is  
I want to know how to configure Tomcat 10 to not loose session data that tells 
the user has successfully logged in




Rick Noel
Systems Programmer | Westwood One
rn...@westwoodone.com

-Original Message-
From: Christopher Schultz  
Sent: Friday, March 15, 2024 12:19 PM
To: users@tomcat.apache.org
Subject: [EXT]Re: 404 for j_security_check

[You don't often get email from ch...@christopherschultz.net. Learn why this is 
important at https://aka.ms/LearnAboutSenderIdentification ]

Rick,

On 3/14/24 15:37, Rick Noel wrote:
> After moving from tomcat 9 to tomcat 10 after a user successfully logs 
> in and then hits a restricted page, the login page is hit again but on 
> this second login hit I get 404 page not found
This is actually expected, since j_security_check is only supposed to be used 
when the container (Tomcat) interrupts a user workflow to request 
authentication.

> How do I set the correct path in my  login jsp so that 
> j_security_check is found?
>
> BTW  I actually am wondering why a  successful logged on user would 
> even be sent to the log in page again?
That's more of a question for your application than anything else.

> My login page  is ->   /membership/login.jsp
>
> Here is how I set the path to  j_security_check in above login.jsp
>
> 
>
> My restricted  web.xml snippet

Are you doing what I call a "direct login" where you have a "login page"
that most users hit first. Like from example.com/app/ where there is no initial 
request for a protected resource? Or are your users always (1) requesting a 
protected resource then (2) Tomcat requests authentication then (3) the user is 
forwarded to the resource originally requested in (1)?

> 
> 
> External
> /external/*
> 
> 
> radiovoodoo
> 
> 
> NONE
> 
> 
> 
> 
> Auth
> /auth/*
> 
> 
> radiovoodoo
> 
> 
> NONE
> 
> 
> 
> FORM
> 
> /membership/login.jsp
> /membership/error.jsp
> 
> 

Those NONE lines look weird to me. 
Why are you explicitly specifying those? What part of your configuration 
actually requests authentication and authorization?

-chris

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

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you know the sender and you are sure the 
content is safe. Please report the message using the Report Message feature in 
your email client if you believe the email is suspicious.


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

Re: 404 for j_security_check

[Christopher Schultz]

Rick,

On 3/14/24 15:37, Rick Noel wrote:

After moving from tomcat 9 to tomcat 10 after a user successfully
logs in and then hits a restricted page, the login page is hit again
but on this second login hit I get 404 page not found
This is actually expected, since j_security_check is only supposed to be 
used when the container (Tomcat) interrupts a user workflow to request 
authentication.



How do I set the correct path in my  login jsp so that
j_security_check is found?

BTW  I actually am wondering why a  successful logged on user would
even be sent to the log in page again?

That's more of a question for your application than anything else.


My login page  is ->   /membership/login.jsp

Here is how I set the path to  j_security_check in above login.jsp



My restricted  web.xml snippet


Are you doing what I call a "direct login" where you have a "login page" 
that most users hit first. Like from example.com/app/ where there is no 
initial request for a protected resource? Or are your users always (1) 
requesting a protected resource then (2) Tomcat requests authentication 
then (3) the user is forwarded to the resource originally requested in (1)?





External
/external/*


radiovoodoo


NONE




Auth
/auth/*


radiovoodoo


NONE



FORM

/membership/login.jsp
/membership/error.jsp




Those NONE lines look weird 
to me. Why are you explicitly specifying those? What part of your 
configuration actually requests authentication and authorization?


-chris

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

404 for j_security_check

[Rick Noel]

After moving from tomcat 9 to tomcat 10after a user successfully logs in 
and then hits a restricted page,  the login page is hit again but on  this 
second login hit I get 404 page not found

How do I set the correct path in my  login jsp so that   j_security_check is 
found?

BTW  I actually am wondering why a  successful logged on user would even be 
sent to the log in page again?


My login page  is ->   /membership/login.jsp

Here is how I set the path to  j_security_check in above login.jsp



My restricted  web.xml snippet




External
/external/*


radiovoodoo


NONE




Auth
/auth/*


radiovoodoo


NONE



FORM

/membership/login.jsp
/membership/error.jsp











Rick Noel
Systems Programmer | Westwood One
rn...@westwoodone.com

Re: Tomcat 9 returning 404 for audio files

[Christopher Schultz]

Sam,

On 3/13/24 22:34, Sam wrote:

Thank you so much!

Finally issue is resolved.

Regards!

On Tue, Mar 12, 2024, 11:43 p.m. Anson Cheung 
wrote:


ok,it's a problem caused by tomcat cache. You need to disable it. Please
refer to

https://serverfault.com/questions/40205/how-do-i-disable-tomcat-caching-im-having-weird-static-file-problems

On Wed, Mar 13, 2024 at 3:46 AM Chuck Caldarale  wrote:




On Mar 12, 2024, at 13:15, Sam  wrote:

As I said earlier, 404 error is only returned 1st time.

Subsequent requests work fine.



What triggers the creation of the audio file? Is it possible that the
trigger creates a file-not-found state in the Tomcat resource cache, and
that’s what is returned the first time?


If disabling your cache "[finally resolved your issue]" then everyone 
who was asking if you were triggering a file-read through Tomcat was 
correct, even though you kept telling them they were wrong.


-chris

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

Re: Tomcat 9 returning 404 for audio files

[Sam]

Thank you so much!

Finally issue is resolved.

Regards!

On Tue, Mar 12, 2024, 11:43 p.m. Anson Cheung 
wrote:

> ok,it's a problem caused by tomcat cache. You need to disable it. Please
> refer to
>
> https://serverfault.com/questions/40205/how-do-i-disable-tomcat-caching-im-having-weird-static-file-problems
>
> On Wed, Mar 13, 2024 at 3:46 AM Chuck Caldarale  wrote:
>
> >
> > > On Mar 12, 2024, at 13:15, Sam  wrote:
> > >
> > > As I said earlier, 404 error is only returned 1st time.
> > >
> > > Subsequent requests work fine.
> >
> >
> > What triggers the creation of the audio file? Is it possible that the
> > trigger creates a file-not-found state in the Tomcat resource cache, and
> > that’s what is returned the first time?
> >
> >   - Chuck
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >
>

Re: Tomcat 9 returning 404 for audio files

[Anson Cheung]

ok,it's a problem caused by tomcat cache. You need to disable it. Please
refer to
https://serverfault.com/questions/40205/how-do-i-disable-tomcat-caching-im-having-weird-static-file-problems

On Wed, Mar 13, 2024 at 3:46 AM Chuck Caldarale  wrote:

>
> > On Mar 12, 2024, at 13:15, Sam  wrote:
> >
> > As I said earlier, 404 error is only returned 1st time.
> >
> > Subsequent requests work fine.
>
>
> What triggers the creation of the audio file? Is it possible that the
> trigger creates a file-not-found state in the Tomcat resource cache, and
> that’s what is returned the first time?
>
>   - Chuck
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Tomcat 9 returning 404 for audio files

[Chuck Caldarale]

> On Mar 12, 2024, at 13:15, Sam  wrote:
> 
> As I said earlier, 404 error is only returned 1st time.
> 
> Subsequent requests work fine.


What triggers the creation of the audio file? Is it possible that the trigger 
creates a file-not-found state in the Tomcat resource cache, and that’s what is 
returned the first time?

  - Chuck


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

Re: Tomcat 9 returning 404 for audio files

[Sam]

Hi,

Yes, path is tomcat/webapps/ROOT/wav/

As I said earlier, 404 error is only returned 1st time.

Subsequent requests work fine.


On Tue, Mar 12, 2024, 3:13 a.m. Anson Cheung 
wrote:

> src="/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3"
> Please confirm that your file is placed under the path
> "/apache-tomcat-9.0.30/webapps/ROOT/wav/"   not " /wav/ "
>
> On Tue, Mar 12, 2024 at 11:20 AM Sam  wrote:
>
> > Hi Chris,
> >
> > I'm creating the audio file dynamically from DB and  I check if the file
> > exists using File.exists() method.
> >
> > Before returning the html code with audio tag, I'm verifying that file
> > exists on File System.
> >
> > Thanks!
> >
> > On Mon, Mar 11, 2024 at 2:36 PM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > > Sam,
> > >
> > > On 3/11/24 13:04, Sam wrote:
> > > > On the server side, I'm checking that file exists before returning
> the
> > > file
> > > > path to the browser. We are also dynamically creating pdf files this
> > way
> > > > and no issues with accessing them.
> > >
> > > How are you checking to see if the file exists? It's possible that your
> > > check-for-existance triggers the "not found" in Tomcat's 
> > > instance, then you create your file on-disk and return the path to the
> > > browser, then the browser requests the path and gets the cached "not
> > > found".
> > >
> > > > I found something interesting:
> > > > https://tomcat.apache.org/tomcat-9.0-doc/config/resources.html From
> > this
> > > > link:
> > > > *Resources are cached by default.*
> > > >
> > > > I'll try with *Cache-Control* request header and see if it helps!
> > >
> > > This isn't likey to be the problem. I think the cache you are fighting
> > > is the one Tomcat maintains for "resources" which is how Tomcat loads
> > > things from ... well, everywhere. Not caching things like "not found"
> > > makes things go very slowly.
> > >
> > > -chris
> > >
> > > > On Mon, Mar 11, 2024 at 11:46 AM Mark Thomas 
> wrote:
> > > >
> > > >> On 11/03/2024 11:31, Sam wrote:
> > > >>> Thanks for replying!!
> > > >>>
> > > >>> Yes audio files are generated dynamically from DB.in a Servlet.
> > > >>>
> > > >>> I've verified that audio file exists on file system before
> returning
> > > the
> > > >>> html code that contains audo control.
> > > >>
> > > >> Is there any chance of an attempt to access the file before it is
> > > >> created? The resources implementation can cache "not found" results
> > for
> > > >> a short period of time.
> > > >>
> > > >> You might want to test the code with a simple text file to determine
> > > >> whether file type is a factor (which seems unlikely but you never
> > know).
> > > >>
> > > >> Mark
> > > >>
> > > >>>
> > > >>>
> > > >>> On Mon, Mar 11, 2024, 5:22 a.m. Mark Thomas 
> > wrote:
> > > >>>
> > > >>>> On 11/03/2024 02:21, Sam wrote:
> > > >>>>> I just upgraded a legacy application from Tomcat 7 to Tomcat 9.
> > It's
> > > >>>>> deployed as a war file. I'm facing a weird issue with audio files
> > > >>>> playback.
> > > >>>>>
> > > >>>>> When loading a page that contains an audio file. First time
> Tomcat
> > > >>>> returns
> > > >>>>> 404 error but if reloading the page, audio file is loaded
> properly
> > > and
> > > >> no
> > > >>>>> error from Tomcat.
> > > >>>>>
> > > >>>>> I'm using html 5 audio control to display the file.
> > > >>>>>
> > > >>>>> All other static resources(images, css and js files) are working
> > > >> without
> > > >>>>> any issues. Only audio files are having this issue.
> > > >>>>>
> > > >>>>> I enabled the logs for DefaultServlet in Tomcat. Follwong is the
> > log
> > > >>>> entry
> > > >>

Re: Tomcat 9 returning 404 for audio files

[Anson Cheung]

src="/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3"
Please confirm that your file is placed under the path
"/apache-tomcat-9.0.30/webapps/ROOT/wav/"   not " /wav/ "

On Tue, Mar 12, 2024 at 11:20 AM Sam  wrote:

> Hi Chris,
>
> I'm creating the audio file dynamically from DB and  I check if the file
> exists using File.exists() method.
>
> Before returning the html code with audio tag, I'm verifying that file
> exists on File System.
>
> Thanks!
>
> On Mon, Mar 11, 2024 at 2:36 PM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
> > Sam,
> >
> > On 3/11/24 13:04, Sam wrote:
> > > On the server side, I'm checking that file exists before returning the
> > file
> > > path to the browser. We are also dynamically creating pdf files this
> way
> > > and no issues with accessing them.
> >
> > How are you checking to see if the file exists? It's possible that your
> > check-for-existance triggers the "not found" in Tomcat's 
> > instance, then you create your file on-disk and return the path to the
> > browser, then the browser requests the path and gets the cached "not
> > found".
> >
> > > I found something interesting:
> > > https://tomcat.apache.org/tomcat-9.0-doc/config/resources.html From
> this
> > > link:
> > > *Resources are cached by default.*
> > >
> > > I'll try with *Cache-Control* request header and see if it helps!
> >
> > This isn't likey to be the problem. I think the cache you are fighting
> > is the one Tomcat maintains for "resources" which is how Tomcat loads
> > things from ... well, everywhere. Not caching things like "not found"
> > makes things go very slowly.
> >
> > -chris
> >
> > > On Mon, Mar 11, 2024 at 11:46 AM Mark Thomas  wrote:
> > >
> > >> On 11/03/2024 11:31, Sam wrote:
> > >>> Thanks for replying!!
> > >>>
> > >>> Yes audio files are generated dynamically from DB.in a Servlet.
> > >>>
> > >>> I've verified that audio file exists on file system before returning
> > the
> > >>> html code that contains audo control.
> > >>
> > >> Is there any chance of an attempt to access the file before it is
> > >> created? The resources implementation can cache "not found" results
> for
> > >> a short period of time.
> > >>
> > >> You might want to test the code with a simple text file to determine
> > >> whether file type is a factor (which seems unlikely but you never
> know).
> > >>
> > >> Mark
> > >>
> > >>>
> > >>>
> > >>> On Mon, Mar 11, 2024, 5:22 a.m. Mark Thomas 
> wrote:
> > >>>
> > >>>> On 11/03/2024 02:21, Sam wrote:
> > >>>>> I just upgraded a legacy application from Tomcat 7 to Tomcat 9.
> It's
> > >>>>> deployed as a war file. I'm facing a weird issue with audio files
> > >>>> playback.
> > >>>>>
> > >>>>> When loading a page that contains an audio file. First time Tomcat
> > >>>> returns
> > >>>>> 404 error but if reloading the page, audio file is loaded properly
> > and
> > >> no
> > >>>>> error from Tomcat.
> > >>>>>
> > >>>>> I'm using html 5 audio control to display the file.
> > >>>>>
> > >>>>> All other static resources(images, css and js files) are working
> > >> without
> > >>>>> any issues. Only audio files are having this issue.
> > >>>>>
> > >>>>> I enabled the logs for DefaultServlet in Tomcat. Follwong is the
> log
> > >>>> entry
> > >>>>> when I try to open the audio file first time. I can see 404 being
> > >>>> returned
> > >>>>> from server in Chrome dev tools.
> > >>>>>
> > >>>>>
> > >>>>> *09-Mar-2024 20:12:50.747 INFO DefaultServlet.serveResource:
> Serving
> > >>>>> resource '/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3'
> headers
> > >> and
> > >>>>> data*
> > >>>>> Following is the log for 2nd attempt. This time audio is available
> &g

Re: Tomcat 9 returning 404 for audio files

[Sam]

Hi Chris,

I'm creating the audio file dynamically from DB and  I check if the file
exists using File.exists() method.

Before returning the html code with audio tag, I'm verifying that file
exists on File System.

Thanks!

On Mon, Mar 11, 2024 at 2:36 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Sam,
>
> On 3/11/24 13:04, Sam wrote:
> > On the server side, I'm checking that file exists before returning the
> file
> > path to the browser. We are also dynamically creating pdf files this way
> > and no issues with accessing them.
>
> How are you checking to see if the file exists? It's possible that your
> check-for-existance triggers the "not found" in Tomcat's 
> instance, then you create your file on-disk and return the path to the
> browser, then the browser requests the path and gets the cached "not
> found".
>
> > I found something interesting:
> > https://tomcat.apache.org/tomcat-9.0-doc/config/resources.html From this
> > link:
> > *Resources are cached by default.*
> >
> > I'll try with *Cache-Control* request header and see if it helps!
>
> This isn't likey to be the problem. I think the cache you are fighting
> is the one Tomcat maintains for "resources" which is how Tomcat loads
> things from ... well, everywhere. Not caching things like "not found"
> makes things go very slowly.
>
> -chris
>
> > On Mon, Mar 11, 2024 at 11:46 AM Mark Thomas  wrote:
> >
> >> On 11/03/2024 11:31, Sam wrote:
> >>> Thanks for replying!!
> >>>
> >>> Yes audio files are generated dynamically from DB.in a Servlet.
> >>>
> >>> I've verified that audio file exists on file system before returning
> the
> >>> html code that contains audo control.
> >>
> >> Is there any chance of an attempt to access the file before it is
> >> created? The resources implementation can cache "not found" results for
> >> a short period of time.
> >>
> >> You might want to test the code with a simple text file to determine
> >> whether file type is a factor (which seems unlikely but you never know).
> >>
> >> Mark
> >>
> >>>
> >>>
> >>> On Mon, Mar 11, 2024, 5:22 a.m. Mark Thomas  wrote:
> >>>
> >>>> On 11/03/2024 02:21, Sam wrote:
> >>>>> I just upgraded a legacy application from Tomcat 7 to Tomcat 9. It's
> >>>>> deployed as a war file. I'm facing a weird issue with audio files
> >>>> playback.
> >>>>>
> >>>>> When loading a page that contains an audio file. First time Tomcat
> >>>> returns
> >>>>> 404 error but if reloading the page, audio file is loaded properly
> and
> >> no
> >>>>> error from Tomcat.
> >>>>>
> >>>>> I'm using html 5 audio control to display the file.
> >>>>>
> >>>>> All other static resources(images, css and js files) are working
> >> without
> >>>>> any issues. Only audio files are having this issue.
> >>>>>
> >>>>> I enabled the logs for DefaultServlet in Tomcat. Follwong is the log
> >>>> entry
> >>>>> when I try to open the audio file first time. I can see 404 being
> >>>> returned
> >>>>> from server in Chrome dev tools.
> >>>>>
> >>>>>
> >>>>> *09-Mar-2024 20:12:50.747 INFO DefaultServlet.serveResource: Serving
> >>>>> resource '/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers
> >> and
> >>>>> data*
> >>>>> Following is the log for 2nd attempt. This time audio is available
> and
> >>>>> playable in browser. *09-Mar-2024 20:13:00.371 INFO
> >>>>> DefaultServlet.serveResource: Serving resource
> >>>>> '/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers and data
> *
> >>>>> *09-Mar-2024 20:13:01.372 INFO DefaultServlet.serveFile:
> >>>>> contentType='audio/mpeg'*
> >>>>
> >>>> Are the audio files generated dynamically on request?
> >>>>
> >>>> Mark
> >>>>
> >>>>
> >>>>>
> >>>>> Here is the audio control code:
> >>>>>
> >>>>> 
> >>>>>>>>>>>
> >>>>>   >>>
> >>>>> >> src="/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3"
> >>>>> type="audio/mpeg" >
> >>>>>  
> >>>>>   
> >>>>> 
> >>>>> I've tried relative path and full path but result is the same in both
> >>>> cases.
> >>>>>
> >>>>> I've spent days trying to solve this but no luck :(
> >>>>>
> >>>>> I would really appreciate any guidance to solve this issue.
> >>>>>
> >>>>> Thanks!
> >>>>>
> >>>>
> >>>> -
> >>>> 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: Tomcat 9 returning 404 for audio files

[Christopher Schultz]

Sam,

On 3/11/24 13:04, Sam wrote:

On the server side, I'm checking that file exists before returning the file
path to the browser. We are also dynamically creating pdf files this way
and no issues with accessing them.


How are you checking to see if the file exists? It's possible that your 
check-for-existance triggers the "not found" in Tomcat's  
instance, then you create your file on-disk and return the path to the 
browser, then the browser requests the path and gets the cached "not found".



I found something interesting:
https://tomcat.apache.org/tomcat-9.0-doc/config/resources.html From this
link:
*Resources are cached by default.*

I'll try with *Cache-Control* request header and see if it helps!


This isn't likey to be the problem. I think the cache you are fighting 
is the one Tomcat maintains for "resources" which is how Tomcat loads 
things from ... well, everywhere. Not caching things like "not found" 
makes things go very slowly.


-chris


On Mon, Mar 11, 2024 at 11:46 AM Mark Thomas  wrote:


On 11/03/2024 11:31, Sam wrote:

Thanks for replying!!

Yes audio files are generated dynamically from DB.in a Servlet.

I've verified that audio file exists on file system before returning the
html code that contains audo control.


Is there any chance of an attempt to access the file before it is
created? The resources implementation can cache "not found" results for
a short period of time.

You might want to test the code with a simple text file to determine
whether file type is a factor (which seems unlikely but you never know).

Mark




On Mon, Mar 11, 2024, 5:22 a.m. Mark Thomas  wrote:


On 11/03/2024 02:21, Sam wrote:

I just upgraded a legacy application from Tomcat 7 to Tomcat 9. It's
deployed as a war file. I'm facing a weird issue with audio files

playback.


When loading a page that contains an audio file. First time Tomcat

returns

404 error but if reloading the page, audio file is loaded properly and

no

error from Tomcat.

I'm using html 5 audio control to display the file.

All other static resources(images, css and js files) are working

without

any issues. Only audio files are having this issue.

I enabled the logs for DefaultServlet in Tomcat. Follwong is the log

entry

when I try to open the audio file first time. I can see 404 being

returned

from server in Chrome dev tools.


*09-Mar-2024 20:12:50.747 INFO DefaultServlet.serveResource: Serving
resource '/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers

and

data*
Following is the log for 2nd attempt. This time audio is available and
playable in browser. *09-Mar-2024 20:13:00.371 INFO
DefaultServlet.serveResource: Serving resource
'/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers and data *
*09-Mar-2024 20:13:01.372 INFO DefaultServlet.serveFile:
contentType='audio/mpeg'*


Are the audio files generated dynamically on request?

Mark




Here is the audio control code:


  
bottom:0;"



 


   
src="/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3"

type="audio/mpeg" >
 
  

I've tried relative path and full path but result is the same in both

cases.


I've spent days trying to solve this but no luck :(

I would really appreciate any guidance to solve this issue.

Thanks!



-
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: Tomcat 9 returning 404 for audio files

[Sam]

Service is running on Windows, I've verified no access issues!

Issue occurs only the first time, Subsequently audio loads properly.

Thank you!

On Mon, Mar 11, 2024 at 12:43 PM Ivano Luberti 
wrote:

> Could it be the file is created with incorrect access rights?
>
> Il 11/03/2024 16:46, Mark Thomas ha scritto:
> > On 11/03/2024 11:31, Sam wrote:
> >> Thanks for replying!!
> >>
> >> Yes audio files are generated dynamically from DB.in a Servlet.
> >>
> >> I've verified that audio file exists on file system before returning the
> >> html code that contains audo control.
> >
> > Is there any chance of an attempt to access the file before it is
> > created? The resources implementation can cache "not found" results
> > for a short period of time.
> >
> > You might want to test the code with a simple text file to determine
> > whether file type is a factor (which seems unlikely but you never know).
> >
> > Mark
> >
> >>
> >>
> >> On Mon, Mar 11, 2024, 5:22 a.m. Mark Thomas  wrote:
> >>
> >>> On 11/03/2024 02:21, Sam wrote:
> >>>> I just upgraded a legacy application from Tomcat 7 to Tomcat 9. It's
> >>>> deployed as a war file. I'm facing a weird issue with audio files
> >>> playback.
> >>>>
> >>>> When loading a page that contains an audio file. First time Tomcat
> >>> returns
> >>>> 404 error but if reloading the page, audio file is loaded properly
> >>>> and no
> >>>> error from Tomcat.
> >>>>
> >>>> I'm using html 5 audio control to display the file.
> >>>>
> >>>> All other static resources(images, css and js files) are working
> >>>> without
> >>>> any issues. Only audio files are having this issue.
> >>>>
> >>>> I enabled the logs for DefaultServlet in Tomcat. Follwong is the log
> >>> entry
> >>>> when I try to open the audio file first time. I can see 404 being
> >>> returned
> >>>> from server in Chrome dev tools.
> >>>>
> >>>>
> >>>> *09-Mar-2024 20:12:50.747 INFO DefaultServlet.serveResource: Serving
> >>>> resource '/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3'
> >>>> headers and
> >>>> data*
> >>>> Following is the log for 2nd attempt. This time audio is available and
> >>>> playable in browser. *09-Mar-2024 20:13:00.371 INFO
> >>>> DefaultServlet.serveResource: Serving resource
> >>>> '/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers and data *
> >>>> *09-Mar-2024 20:13:01.372 INFO DefaultServlet.serveFile:
> >>>> contentType='audio/mpeg'*
> >>>
> >>> Are the audio files generated dynamically on request?
> >>>
> >>> Mark
> >>>
> >>>
> >>>>
> >>>> Here is the audio control code:
> >>>>
> >>>> 
> >>>>   >>>>>
> >>>> 
> >>>>>>>> src="/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3"
> >>>> type="audio/mpeg" >
> >>>> 
> >>>>  
> >>>> 
> >>>> I've tried relative path and full path but result is the same in both
> >>> cases.
> >>>>
> >>>> I've spent days trying to solve this but no luck :(
> >>>>
> >>>> I would really appreciate any guidance to solve this issue.
> >>>>
> >>>> Thanks!
> >>>>
> >>>
> >>> -
> >>> 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
> >
> --
>
> Archimede Informatica tratta i dati personali in conformità a quanto
> stabilito dal Regolamento UE n. 2016/679 (GDPR) e dal D. Lgs. 30 giugno
> 2003 n. 196
> per come modificato dal D.Lgs. 10 agosto 2018 n. 101.
> Informativa completa
> <
> http://www.archicoop.it/fileadmin/pdf/InformativaTrattamentoDatiPersonali.pdf
> >
>
> Il contenuto di questo messaggio e dei suoi eventuali allegati è
> riservato. Nel caso in cui Lei non sia il destinatario, La preghiamo di
> contattare telefonicamente o via e-mail il mittente ai recapiti sopra
> indicati e di cancellare il messaggio e gli eventuali allegati dal Suo
> sistema senza farne copia o diffonderli. Le opinioni espresse sono
> quelle dell'autore e non rappresentano necessariamente quelle della
> Società.
> This message and any attachment are confidential.If you are not the
> intended recipient, please telephone or email the sender and delete this
> message and any attachment from your system. If you are not the intended
> recipient you must not copy this message or attachment or disclose the
> contents to any other person. Any opinions presented are solely those of
> the author and do not necessarily represent those of the Company.
>
> dott. Ivano Mario Luberti
>
> Archimede Informatica società cooperativa a r. l.
> Via Gereschi 36, 56127 Pisa
>
> tel.: +39 050/580959 | fax: +39 050/8932061
>
> web: www.archicoop.it
> linkedin: www.linkedin.com/in/ivanoluberti
> facebook: www.facebook.com/archimedeinformaticapisa/
>

Re: Tomcat 9 returning 404 for audio files

[Sam]

On the server side, I'm checking that file exists before returning the file
path to the browser. We are also dynamically creating pdf files this way
and no issues with accessing them.

I found something interesting:
https://tomcat.apache.org/tomcat-9.0-doc/config/resources.html From this
link:
*Resources are cached by default.*

I'll try with *Cache-Control* request header and see if it helps!

Thank you!

On Mon, Mar 11, 2024 at 11:46 AM Mark Thomas  wrote:

> On 11/03/2024 11:31, Sam wrote:
> > Thanks for replying!!
> >
> > Yes audio files are generated dynamically from DB.in a Servlet.
> >
> > I've verified that audio file exists on file system before returning the
> > html code that contains audo control.
>
> Is there any chance of an attempt to access the file before it is
> created? The resources implementation can cache "not found" results for
> a short period of time.
>
> You might want to test the code with a simple text file to determine
> whether file type is a factor (which seems unlikely but you never know).
>
> Mark
>
> >
> >
> > On Mon, Mar 11, 2024, 5:22 a.m. Mark Thomas  wrote:
> >
> >> On 11/03/2024 02:21, Sam wrote:
> >>> I just upgraded a legacy application from Tomcat 7 to Tomcat 9. It's
> >>> deployed as a war file. I'm facing a weird issue with audio files
> >> playback.
> >>>
> >>> When loading a page that contains an audio file. First time Tomcat
> >> returns
> >>> 404 error but if reloading the page, audio file is loaded properly and
> no
> >>> error from Tomcat.
> >>>
> >>> I'm using html 5 audio control to display the file.
> >>>
> >>> All other static resources(images, css and js files) are working
> without
> >>> any issues. Only audio files are having this issue.
> >>>
> >>> I enabled the logs for DefaultServlet in Tomcat. Follwong is the log
> >> entry
> >>> when I try to open the audio file first time. I can see 404 being
> >> returned
> >>> from server in Chrome dev tools.
> >>>
> >>>
> >>> *09-Mar-2024 20:12:50.747 INFO DefaultServlet.serveResource: Serving
> >>> resource '/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers
> and
> >>> data*
> >>> Following is the log for 2nd attempt. This time audio is available and
> >>> playable in browser. *09-Mar-2024 20:13:00.371 INFO
> >>> DefaultServlet.serveResource: Serving resource
> >>> '/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers and data *
> >>> *09-Mar-2024 20:13:01.372 INFO DefaultServlet.serveFile:
> >>> contentType='audio/mpeg'*
> >>
> >> Are the audio files generated dynamically on request?
> >>
> >> Mark
> >>
> >>
> >>>
> >>> Here is the audio control code:
> >>>
> >>> 
> >>>   >>>>
> >>>  >
> >>>src="/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3"
> >>> type="audio/mpeg" >
> >>> 
> >>>  
> >>> 
> >>> I've tried relative path and full path but result is the same in both
> >> cases.
> >>>
> >>> I've spent days trying to solve this but no luck :(
> >>>
> >>> I would really appreciate any guidance to solve this issue.
> >>>
> >>> Thanks!
> >>>
> >>
> >> -
> >> 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: Tomcat 9 returning 404 for audio files

[Ivano Luberti]

Could it be the file is created with incorrect access rights?

Il 11/03/2024 16:46, Mark Thomas ha scritto:

On 11/03/2024 11:31, Sam wrote:

Thanks for replying!!

Yes audio files are generated dynamically from DB.in a Servlet.

I've verified that audio file exists on file system before returning the
html code that contains audo control.


Is there any chance of an attempt to access the file before it is 
created? The resources implementation can cache "not found" results 
for a short period of time.


You might want to test the code with a simple text file to determine 
whether file type is a factor (which seems unlikely but you never know).


Mark




On Mon, Mar 11, 2024, 5:22 a.m. Mark Thomas  wrote:


On 11/03/2024 02:21, Sam wrote:

I just upgraded a legacy application from Tomcat 7 to Tomcat 9. It's
deployed as a war file. I'm facing a weird issue with audio files

playback.


When loading a page that contains an audio file. First time Tomcat

returns
404 error but if reloading the page, audio file is loaded properly 
and no

error from Tomcat.

I'm using html 5 audio control to display the file.

All other static resources(images, css and js files) are working 
without

any issues. Only audio files are having this issue.

I enabled the logs for DefaultServlet in Tomcat. Follwong is the log

entry

when I try to open the audio file first time. I can see 404 being

returned

from server in Chrome dev tools.


*09-Mar-2024 20:12:50.747 INFO DefaultServlet.serveResource: Serving
resource '/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' 
headers and

data*
Following is the log for 2nd attempt. This time audio is available and
playable in browser. *09-Mar-2024 20:13:00.371 INFO
DefaultServlet.serveResource: Serving resource
'/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers and data *
*09-Mar-2024 20:13:01.372 INFO DefaultServlet.serveFile:
contentType='audio/mpeg'*


Are the audio files generated dynamically on request?

Mark




Here is the audio control code:


 
bottom:0;"


    
  src="/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3"

type="audio/mpeg" >
    
 

I've tried relative path and full path but result is the same in both

cases.


I've spent days trying to solve this but no luck :(

I would really appreciate any guidance to solve this issue.

Thanks!



-
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


--

Archimede Informatica tratta i dati personali in conformità a quanto
stabilito dal Regolamento UE n. 2016/679 (GDPR) e dal D. Lgs. 30 giugno 
2003 n. 196

per come modificato dal D.Lgs. 10 agosto 2018 n. 101.
Informativa completa 
<http://www.archicoop.it/fileadmin/pdf/InformativaTrattamentoDatiPersonali.pdf>


Il contenuto di questo messaggio e dei suoi eventuali allegati è 
riservato. Nel caso in cui Lei non sia il destinatario, La preghiamo di 
contattare telefonicamente o via e-mail il mittente ai recapiti sopra 
indicati e di cancellare il messaggio e gli eventuali allegati dal Suo 
sistema senza farne copia o diffonderli. Le opinioni espresse sono 
quelle dell'autore e non rappresentano necessariamente quelle della Società.
This message and any attachment are confidential.If you are not the 
intended recipient, please telephone or email the sender and delete this 
message and any attachment from your system. If you are not the intended 
recipient you must not copy this message or attachment or disclose the 
contents to any other person. Any opinions presented are solely those of 
the author and do not necessarily represent those of the Company.


dott. Ivano Mario Luberti

Archimede Informatica società cooperativa a r. l.
Via Gereschi 36, 56127 Pisa

tel.: +39 050/580959 | fax: +39 050/8932061

web: www.archicoop.it
linkedin: www.linkedin.com/in/ivanoluberti
facebook: www.facebook.com/archimedeinformaticapisa/

Re: Tomcat 9 returning 404 for audio files

[Mark Thomas]

On 11/03/2024 11:31, Sam wrote:

Thanks for replying!!

Yes audio files are generated dynamically from DB.in a Servlet.

I've verified that audio file exists on file system before returning the
html code that contains audo control.


Is there any chance of an attempt to access the file before it is 
created? The resources implementation can cache "not found" results for 
a short period of time.


You might want to test the code with a simple text file to determine 
whether file type is a factor (which seems unlikely but you never know).


Mark




On Mon, Mar 11, 2024, 5:22 a.m. Mark Thomas  wrote:


On 11/03/2024 02:21, Sam wrote:

I just upgraded a legacy application from Tomcat 7 to Tomcat 9. It's
deployed as a war file. I'm facing a weird issue with audio files

playback.


When loading a page that contains an audio file. First time Tomcat

returns

404 error but if reloading the page, audio file is loaded properly and no
error from Tomcat.

I'm using html 5 audio control to display the file.

All other static resources(images, css and js files) are working without
any issues. Only audio files are having this issue.

I enabled the logs for DefaultServlet in Tomcat. Follwong is the log

entry

when I try to open the audio file first time. I can see 404 being

returned

from server in Chrome dev tools.


*09-Mar-2024 20:12:50.747 INFO DefaultServlet.serveResource: Serving
resource '/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers and
data*
Following is the log for 2nd attempt. This time audio is available and
playable in browser. *09-Mar-2024 20:13:00.371 INFO
DefaultServlet.serveResource: Serving resource
'/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers and data *
*09-Mar-2024 20:13:01.372 INFO DefaultServlet.serveFile:
contentType='audio/mpeg'*


Are the audio files generated dynamically on request?

Mark




Here is the audio control code:


 
bottom:0;"




  

 

I've tried relative path and full path but result is the same in both

cases.


I've spent days trying to solve this but no luck :(

I would really appreciate any guidance to solve this issue.

Thanks!



-
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: [EXTERNAL] Re: Tomcat 9 returning 404 for audio files

[Robert Turner]

It's also possible you may need to support the "Range" HTTP header for
fetching parts of the audio file for playback. IIRC, we had to do that to
support the HTML 5 audio control properly.

On Mon, Mar 11, 2024 at 9:15 AM Joey Cochran  wrote:

> Thanks for replying!!
>
> Yes audio files are generated dynamically from DB.in a Servlet.
>
> I've verified that audio file exists on file system before returning the
> html code that contains audo control.
>
> I do NOT see this as a server side issue.
> This reads like a client/DOM cache of resource issue with the HTML5 audio
> control.
> simple fix could be (on the return/callback handler) to either
> refresh/reload just that tag on the DOM or even throw a whole DOM reload
> (more than one way to accomplish these, hence keeping it a pseudo code
> response)  -Hope this helps!
> -Joey
>
> On Mon, Mar 11, 2024, 5:22 a.m. Mark Thomas  wrote:
>
> > On 11/03/2024 02:21, Sam wrote:
> > > I just upgraded a legacy application from Tomcat 7 to Tomcat 9. It's
> > > deployed as a war file. I'm facing a weird issue with audio files
> > playback.
> > >
> > > When loading a page that contains an audio file. First time Tomcat
> > returns
> > > 404 error but if reloading the page, audio file is loaded properly and
> no
> > > error from Tomcat.
> > >
> > > I'm using html 5 audio control to display the file.
> > >
> > > All other static resources(images, css and js files) are working
> without
> > > any issues. Only audio files are having this issue.
> > >
> > > I enabled the logs for DefaultServlet in Tomcat. Follwong is the log
> > entry
> > > when I try to open the audio file first time. I can see 404 being
> > returned
> > > from server in Chrome dev tools.
> > >
> > >
> > > *09-Mar-2024 20:12:50.747 INFO DefaultServlet.serveResource: Serving
> > > resource '/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers
> and
> > > data*
> > > Following is the log for 2nd attempt. This time audio is available and
> > > playable in browser. *09-Mar-2024 20:13:00.371 INFO
> > > DefaultServlet.serveResource: Serving resource
> > > '/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers and data *
> > > *09-Mar-2024 20:13:01.372 INFO DefaultServlet.serveFile:
> > > contentType='audio/mpeg'*
> >
> > Are the audio files generated dynamically on request?
> >
> > Mark
> >
> >
> > >
> > > Here is the audio control code:
> > >
> > > 
> > >  > >>
> > >
> > >   src="/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3"
> > > type="audio/mpeg" >
> > >
> > > 
> > > 
> > > I've tried relative path and full path but result is the same in both
> > cases.
> > >
> > > I've spent days trying to solve this but no luck :(
> > >
> > > I would really appreciate any guidance to solve this issue.
> > >
> > > Thanks!
> > >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >
>

Re: [EXTERNAL] Re: Tomcat 9 returning 404 for audio files

[Joey Cochran]

Thanks for replying!!

Yes audio files are generated dynamically from DB.in a Servlet.

I've verified that audio file exists on file system before returning the
html code that contains audo control.

I do NOT see this as a server side issue.
This reads like a client/DOM cache of resource issue with the HTML5 audio 
control.
simple fix could be (on the return/callback handler) to either refresh/reload 
just that tag on the DOM or even throw a whole DOM reload (more than one way to 
accomplish these, hence keeping it a pseudo code response)  -Hope this helps!
-Joey

On Mon, Mar 11, 2024, 5:22 a.m. Mark Thomas  wrote:

> On 11/03/2024 02:21, Sam wrote:
> > I just upgraded a legacy application from Tomcat 7 to Tomcat 9. It's
> > deployed as a war file. I'm facing a weird issue with audio files
> playback.
> >
> > When loading a page that contains an audio file. First time Tomcat
> returns
> > 404 error but if reloading the page, audio file is loaded properly and no
> > error from Tomcat.
> >
> > I'm using html 5 audio control to display the file.
> >
> > All other static resources(images, css and js files) are working without
> > any issues. Only audio files are having this issue.
> >
> > I enabled the logs for DefaultServlet in Tomcat. Follwong is the log
> entry
> > when I try to open the audio file first time. I can see 404 being
> returned
> > from server in Chrome dev tools.
> >
> >
> > *09-Mar-2024 20:12:50.747 INFO DefaultServlet.serveResource: Serving
> > resource '/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers and
> > data*
> > Following is the log for 2nd attempt. This time audio is available and
> > playable in browser. *09-Mar-2024 20:13:00.371 INFO
> > DefaultServlet.serveResource: Serving resource
> > '/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers and data *
> > *09-Mar-2024 20:13:01.372 INFO DefaultServlet.serveFile:
> > contentType='audio/mpeg'*
>
> Are the audio files generated dynamically on request?
>
> Mark
>
>
> >
> > Here is the audio control code:
> >
> > 
> >  >>
> >
> >   > type="audio/mpeg" >
> >
> > 
> > 
> > I've tried relative path and full path but result is the same in both
> cases.
> >
> > I've spent days trying to solve this but no luck :(
> >
> > I would really appreciate any guidance to solve this issue.
> >
> > Thanks!
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Tomcat 9 returning 404 for audio files

[Sam]

Thanks for replying!!

Yes audio files are generated dynamically from DB.in a Servlet.

I've verified that audio file exists on file system before returning the
html code that contains audo control.


On Mon, Mar 11, 2024, 5:22 a.m. Mark Thomas  wrote:

> On 11/03/2024 02:21, Sam wrote:
> > I just upgraded a legacy application from Tomcat 7 to Tomcat 9. It's
> > deployed as a war file. I'm facing a weird issue with audio files
> playback.
> >
> > When loading a page that contains an audio file. First time Tomcat
> returns
> > 404 error but if reloading the page, audio file is loaded properly and no
> > error from Tomcat.
> >
> > I'm using html 5 audio control to display the file.
> >
> > All other static resources(images, css and js files) are working without
> > any issues. Only audio files are having this issue.
> >
> > I enabled the logs for DefaultServlet in Tomcat. Follwong is the log
> entry
> > when I try to open the audio file first time. I can see 404 being
> returned
> > from server in Chrome dev tools.
> >
> >
> > *09-Mar-2024 20:12:50.747 INFO DefaultServlet.serveResource: Serving
> > resource '/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers and
> > data*
> > Following is the log for 2nd attempt. This time audio is available and
> > playable in browser. *09-Mar-2024 20:13:00.371 INFO
> > DefaultServlet.serveResource: Serving resource
> > '/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers and data *
> > *09-Mar-2024 20:13:01.372 INFO DefaultServlet.serveFile:
> > contentType='audio/mpeg'*
>
> Are the audio files generated dynamically on request?
>
> Mark
>
>
> >
> > Here is the audio control code:
> >
> > 
> >  >>
> >
> >   > type="audio/mpeg" >
> >
> > 
> > 
> > I've tried relative path and full path but result is the same in both
> cases.
> >
> > I've spent days trying to solve this but no luck :(
> >
> > I would really appreciate any guidance to solve this issue.
> >
> > Thanks!
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Tomcat 9 returning 404 for audio files

[Mark Thomas]

On 11/03/2024 02:21, Sam wrote:

I just upgraded a legacy application from Tomcat 7 to Tomcat 9. It's
deployed as a war file. I'm facing a weird issue with audio files playback.

When loading a page that contains an audio file. First time Tomcat returns
404 error but if reloading the page, audio file is loaded properly and no
error from Tomcat.

I'm using html 5 audio control to display the file.

All other static resources(images, css and js files) are working without
any issues. Only audio files are having this issue.

I enabled the logs for DefaultServlet in Tomcat. Follwong is the log entry
when I try to open the audio file first time. I can see 404 being returned
from server in Chrome dev tools.


*09-Mar-2024 20:12:50.747 INFO DefaultServlet.serveResource: Serving
resource '/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers and
data*
Following is the log for 2nd attempt. This time audio is available and
playable in browser. *09-Mar-2024 20:13:00.371 INFO
DefaultServlet.serveResource: Serving resource
'/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers and data *
*09-Mar-2024 20:13:01.372 INFO DefaultServlet.serveFile:
contentType='audio/mpeg'*


Are the audio files generated dynamically on request?

Mark




Here is the audio control code:





   
 
   


I've tried relative path and full path but result is the same in both cases.

I've spent days trying to solve this but no luck :(

I would really appreciate any guidance to solve this issue.

Thanks!



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

Tomcat 9 returning 404 for audio files

[Sam]

I just upgraded a legacy application from Tomcat 7 to Tomcat 9. It's
deployed as a war file. I'm facing a weird issue with audio files playback.

When loading a page that contains an audio file. First time Tomcat returns
404 error but if reloading the page, audio file is loaded properly and no
error from Tomcat.

I'm using html 5 audio control to display the file.

All other static resources(images, css and js files) are working without
any issues. Only audio files are having this issue.

I enabled the logs for DefaultServlet in Tomcat. Follwong is the log entry
when I try to open the audio file first time. I can see 404 being returned
from server in Chrome dev tools.


*09-Mar-2024 20:12:50.747 INFO DefaultServlet.serveResource: Serving
resource '/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers and
data*
Following is the log for 2nd attempt. This time audio is available and
playable in browser. *09-Mar-2024 20:13:00.371 INFO
DefaultServlet.serveResource: Serving resource
'/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers and data *
*09-Mar-2024 20:13:01.372 INFO DefaultServlet.serveFile:
contentType='audio/mpeg'*

Here is the audio control code:


   
  

  
   

I've tried relative path and full path but result is the same in both cases.

I've spent days trying to solve this but no luck :(

I would really appreciate any guidance to solve this issue.

Thanks!

Re: The custom 404 page of Tomcat8 suddenly becomes invalid

[bigelytechnol...@yahoo.com]

 Hello Dear
Thanks for your reply
l would use this opportunity to briefly introduce our company, Bigly
Technologies Thailand,  We are one of the leading importers in Asia , and
the Middle East on general Goods and Equipment.
On behalf of Bigly Technologies Thailand, this is the samples of the
product that we want develop.
Please Kindly view our website for the samples and the product we need if
your company can
make the similar like this product.
*E-Catalogue:  *https://biglytechcatalog.es.tl

Please quote us your best prices and the cost of delivery to our port and
if the prices meets our
price target we can place our order as soon as possible.
Thank You!

Best Regards

*Wat Namtip*

Purchase Manager

*Bigly Technologies Thailand*

2/51 BangNa Complex Office Tower, 11th Floor, Soi BangNa Trat 25, Bangna
Nua, Bangna, Bangkok 10260 Thailand

Telephone: +66 (0)2150 10 15

On Mon, Feb 19, 2024 at 8:35 AM LeventLee <894793...@qq.com.invalid> wrote:

> Hello,
>
>
> Here is my information：
> openjdk version "1.8.0_345" | OpenJDK Runtime Environment (build
> 1.8.0_345-b01) | OpenJDK 64-Bit Server VM (build 25.345-b01, mixed mode)
>
> Linux 5.10.134-12.al8.x86_64
> Apache Tomcat/8.0.24
>
>
>
> Now, please let me explain the problems encountered：
> Previously, I set up a custom 404 page in tomcat's WEB INF/web.xml, so
> that once the client accesses a non-existent page, it will return to this
> 404 page. However, not long ago, after Tomcat restarted, it was unable to
> return the custom 404 page and only returned the browser's 404 page.
> I have checked the localhost logs of Tomcat and found a large number of
> errors:org.apache.catalina.core.ApplicationContext.log ssi:
> Can't serve file:/WEB-INF/index/my404page
>
> But the custom 404 page does exist,and the path is right.
> I want to figure out what this error means. If possible, maybe can
> try this problem.
>
>
> Thanks in advance for your suggestions!

Re: The custom 404 page of Tomcat8 suddenly becomes invalid

[Mark Thomas]

On 19/02/2024 01:35, LeventLee wrote:

Hello,


Here is my information：
openjdk version "1.8.0_345" | OpenJDK Runtime Environment (build 1.8.0_345-b01) 
| OpenJDK 64-Bit Server VM (build 25.345-b01, mixed mode)

Linux 5.10.134-12.al8.x86_64
Apache Tomcat/8.0.24


That version is over 8 years old.

The 8.0.x has been unsupported for more than 5 years (since 30 Jun 2018).

Note that 8.5.x will reach EOL on 31 March 2024.

You *really* need to upgrade.

Upgrading to 9.0.x will be easiest as it still uses the Java EE APIs. 
You may want to consider an upgrade to 10.1.x but that will be more work 
is there is a package change related to the Java EE to Jakarta EE change.




Now, please let me explain the problems encountered：
Previously, I set up a custom 404 page in tomcat's WEB INF/web.xml, so that 
once the client accesses a non-existent page, it will return to this 404 page. 
However, not long ago, after Tomcat restarted, it was unable to return the 
custom 404 page and only returned the browser's 404 page.
I have checked the localhost logs of Tomcat and found a large number of 
errors:org.apache.catalina.core.ApplicationContext.log ssi:
Can't serve file:/WEB-INF/index/my404page


Is that the full error message?

Why is SSI involved?

Is the rest of the application working correctly?

Mark


But the custom 404 page does exist,and the path is right.
I want to figure out what this error means. If possible, maybe can try 
this problem.


Thanks in advance for your suggestions!


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

Re: Tomcat 8: Random 404 and 505 errors

[Mark Thomas]

On 16/11/2023 22:53, Pavan Veginati wrote:

Hi,
We are seeing random 404 and 505 errors with GET and POST requests.

Out of the 10 million daily requests in one cluster, there are 2-3 such 404 
errors. In another cluster with around 100 million daily requests, we are 
seeing 20-30 404s on average per day.
Requests with a 505 error are rare and only happen once or twice a week.

The same requests were successful a few milliseconds before and after the 
error. The servlet that handles these requests always returns a 200 with an 
appropriate error response if it fails, but never a 404. So, it is surprising 
to see a 404 response.


Hmm. Tomcat returns a 505 response in a single location. It does this 
when it doesn't understand the HTTP version that has been received in 
the request line.


Assuming the clients aren't sending malformed HTTP requests that 
suggests the input buffer is getting corrupted. That form of request 
mix-up is rare but has happened due to both Tomcat bugs and application 
bugs in the past.


I don't think there are any fixes since 8.5.88 that relate to this but 
it would be worth considering updating to 8.5.96.


Do you use any of:
- WebSocket
- Servlet asynchronous API
- Sendfile
- HTTP/2

I'm just trying to narrow down the areas of code we may need to look at.

I think the 505s offer the best opportunity to track this down as they 
only happen in one place and debug logging is available.



We've only had this issue in our test environment (similar to prod) a couple of 
times, but we can't reproduce it again.
I've found a similar issue reported here: 
https://lists.apache.org/thread/rxypsggr36joq8fcd44khjky9w4qf4xx

Deployment Details:
   Tomcat Version:
8.5.88. Built from source.
   Java Version:
JDK 17.
   Network Topology:
Direct server to server internal calls with no load balancers in 
between.

Are there any known issues that could be causing this,


No.


and are there any specific logs we can enable that might help us debug this 
issue further ?


Enable debug logging for the Http11Processor. Add this to 
logging.properties:


org.apache.coyote.http11.Http11Processor.level=FINE

That will log additional detail for most failed requests (but not 404s).

Add %r in the access log pattern which will log the entire request line 
for every request.



For each 404, check the access log and see whether the request line is 
as expected.


For each 505, check both the access log and the standard log files.

If you can provide us with the request lines from the access log for 
each 404 (along with whether or not they are as you expect) and the 
request line and debug log entry for each 505 we will hopefully be able 
draw some further conclusions.


Given you are building from source, one possible investigative option is 
providing you with a custom patch that adds additional debug logging. If 
we reach the point where that would be helpful, is that something you'd 
consider?


Mark

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

Tomcat 8: Random 404 and 505 errors

[Pavan Veginati]

Hi,
We are seeing random 404 and 505 errors with GET and POST requests.

Out of the 10 million daily requests in one cluster, there are 2-3 such 404 
errors. In another cluster with around 100 million daily requests, we are 
seeing 20-30 404s on average per day.
Requests with a 505 error are rare and only happen once or twice a week.

The same requests were successful a few milliseconds before and after the 
error. The servlet that handles these requests always returns a 200 with an 
appropriate error response if it fails, but never a 404. So, it is surprising 
to see a 404 response.

We've only had this issue in our test environment (similar to prod) a couple of 
times, but we can't reproduce it again. 
I've found a similar issue reported here: 
https://lists.apache.org/thread/rxypsggr36joq8fcd44khjky9w4qf4xx

Deployment Details:  
  Tomcat Version:  
8.5.88. Built from source.
  Java Version:  
JDK 17.
  Network Topology:  
Direct server to server internal calls with no load balancers in 
between. 

Are there any known issues that could be causing this, and are there any 
specific logs we can enable that might help us debug this issue further ? 

-- 
Thanks
Pavan

Re: Tomcat 9 -> Intermittent 404 (3-4 fails in 20-30 million requests daily sometimes )

[Christopher Schultz]

Anurag,

On 10/17/23 10:01, Anurag Kumar wrote:

Thanks, Christopher, for looking into this issue.


Wait until I actually help before thanking me. I'm mostly trying to get 
more information so people smarter than I am can maybe help you. ;)



Tomcat version:
Server version: Apache Tomcat/9.0.74
Server built: Apr 13, 2023 08:10:39 UTC
Server number: 9.0.74.0


Would it be at all possible to upgrade to 9.0.latest on one or more of 
your cluster members? You'd have to read the changelog to see if there 
are any incompatibilities but I suspect you should be okay. There are 
constant improvements, and its possible that 6 months (since 9.0.74) has 
improved something that makes a difference for you.


We became aware of this issue a few days ago when it was reported by a 
customer due to a critical internal API failure, where the possibility 
of unexpected characters was none. Upon investigating the Splunk logs, 
we discovered that this issue had been occurring for at least the past 3 
months, based on the available three-month log data.


We have a single servlet mapped for all URL patterns, and we log the 
requests from this servlet. Internally, we always return a 200 response 
code with the appropriate error page and never throw a 404 response.


Do you ever re-deploy your application while Tomcat is running? Which 
file/log contains the 404 responses?



Here is our Connector configuration:

scheme="https" secure="true" executor="httpsThreadPool" 
acceptCount="250" SSLEnabled="false" connectionTimeout="2" 
URIEncoding="utf-8" enableLookups="false" 
relaxedQueryChars="{}|" compression="on"/>



These 404 issues have been observed on requests created from Chrome, 
HttpURLConnection in Java, and AsyncHttpClient in Java. Our servers are 
behind an Amazon Load Balancer (ALB), and while ALB operates on HTTP2, 
our Tomcat servers are configured for HTTP1.


This issue has been reported on all nine different clusters running the 
same Tomcat version. Our test environment closely mirrors the production 
environment, but we have been unable to reproduce the issue so far, even 
after increasing the number of requests.


It's challenging to identify any specific patterns as the occurrences 
appear to be distributed randomly and happen with very simple GET 
requests. There was one instance where I was able to reproduce the issue 
in production with a straightforward GET request after making 45,000 
calls, but it was never reproduced afterwards through my automation.


:/


Request capture on ALB:-
image.png


This list strips images out. Please send plain-text only.

-chris

On Mon, Oct 16, 2023 at 6:16 PM Christopher Schultz 
mailto:ch...@christopherschultz.net>> wrote:


    Anurag,

On 10/15/23 04:48, Anurag Kumar wrote:
 >
 > Hi, we are experiencing intermittent 404 errors with both GET and
POST
 > calls. These errors are quite rare and have proven difficult to
 > reproduce in our testing environment. However, on our production
system,
 > we encounter 3-4 cases daily out of 20-30 million requests where
a 404
 > error appears in the Tomcat access logs, and the corresponding call
 > fails to reach the mapped servlet. Interestingly, the same calls
work
 > perfectly just a few milliseconds before and after on the same node.
 > This inconsistency is causing significant issues, especially when
 > critical API calls fail and are not automatically retried.
 >
 > Is there any open issue related to this problem that we should be
aware of?

None that I know of personally.

Can you post your exact Tomcat version, your  configuration
with any secrets removed and a little more background on the type of
traffic you are seeing (e.g. HTTP/1.1 v h2, TLS or not, etc.). Are you
able to tell if these failed requests are part of any kind of pipelined
requests (HTTP Keep-Alive) or h2 single channels?

Understanding the network topology may be relevant, though its unlikely
that any lb/rp is doing this, as you can see the logs on the Tomcat
node. But it may change the way the requests are being handled based
upon the type of connection between the lb/rp and Tomcat.

Have you double-checked that the URIs are clean and don't contain
anything unexpected such as lookalike characters, etc.? I suspect this
is not an issue since you said "critical API calls fail" which leads me
to understand that you have legitimate customers reporting these
failures, instead of just investigating unexpected entries in your log
files.

Is your testing environment reasonably similar to production? What
would
happen if you were to reply a whole day's worth of production-requests
through your testing environment?

Is there any pattern whatsoever in the f

Re: Tomcat 9 -> Intermittent 404 (3-4 fails in 20-30 million requests daily sometimes )

[Anurag Kumar]

Thanks, Christopher, for looking into this issue.

Tomcat version:
Server version: Apache Tomcat/9.0.74
Server built: Apr 13, 2023 08:10:39 UTC
Server number: 9.0.74.0


We became aware of this issue a few days ago when it was reported by a
customer due to a critical internal API failure, where the possibility of
unexpected characters was none. Upon investigating the Splunk logs, we
discovered that this issue had been occurring for at least the past 3
months, based on the available three-month log data.

We have a single servlet mapped for all URL patterns, and we log the
requests from this servlet. Internally, we always return a 200 response
code with the appropriate error page and never throw a 404 response.

Here is our Connector configuration:




These 404 issues have been observed on requests created from Chrome,
HttpURLConnection in Java, and AsyncHttpClient in Java. Our servers are
behind an Amazon Load Balancer (ALB), and while ALB operates on HTTP2, our
Tomcat servers are configured for HTTP1.

This issue has been reported on all nine different clusters running the
same Tomcat version. Our test environment closely mirrors the production
environment, but we have been unable to reproduce the issue so far, even
after increasing the number of requests.

It's challenging to identify any specific patterns as the occurrences
appear to be distributed randomly and happen with very simple GET requests.
There was one instance where I was able to reproduce the issue in
production with a straightforward GET request after making 45,000 calls,
but it was never reproduced afterwards through my automation.


Request capture on ALB:-
[image: image.png]


Thanks
Anurag Kumar


On Mon, Oct 16, 2023 at 6:16 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Anurag,
>
> On 10/15/23 04:48, Anurag Kumar wrote:
> >
> > Hi, we are experiencing intermittent 404 errors with both GET and POST
> > calls. These errors are quite rare and have proven difficult to
> > reproduce in our testing environment. However, on our production system,
> > we encounter 3-4 cases daily out of 20-30 million requests where a 404
> > error appears in the Tomcat access logs, and the corresponding call
> > fails to reach the mapped servlet. Interestingly, the same calls work
> > perfectly just a few milliseconds before and after on the same node.
> > This inconsistency is causing significant issues, especially when
> > critical API calls fail and are not automatically retried.
> >
> > Is there any open issue related to this problem that we should be aware
> of?
>
> None that I know of personally.
>
> Can you post your exact Tomcat version, your  configuration
> with any secrets removed and a little more background on the type of
> traffic you are seeing (e.g. HTTP/1.1 v h2, TLS or not, etc.). Are you
> able to tell if these failed requests are part of any kind of pipelined
> requests (HTTP Keep-Alive) or h2 single channels?
>
> Understanding the network topology may be relevant, though its unlikely
> that any lb/rp is doing this, as you can see the logs on the Tomcat
> node. But it may change the way the requests are being handled based
> upon the type of connection between the lb/rp and Tomcat.
>
> Have you double-checked that the URIs are clean and don't contain
> anything unexpected such as lookalike characters, etc.? I suspect this
> is not an issue since you said "critical API calls fail" which leads me
> to understand that you have legitimate customers reporting these
> failures, instead of just investigating unexpected entries in your log
> files.
>
> Is your testing environment reasonably similar to production? What would
> happen if you were to reply a whole day's worth of production-requests
> through your testing environment?
>
> Is there any pattern whatsoever in the failed requests? If you look at
> every failed request for all time, are they randomly distributed
> throughout your URI space, or do you find that some URIs are
> over-represented in your failure data? You may have so few failures that
> you can't draw any conclusions.
>
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Tomcat 9 -> Intermittent 404 (3-4 fails in 20-30 million requests daily sometimes )

[Christopher Schultz]

Anurag,

On 10/15/23 04:48, Anurag Kumar wrote:


Hi, we are experiencing intermittent 404 errors with both GET and POST 
calls. These errors are quite rare and have proven difficult to 
reproduce in our testing environment. However, on our production system, 
we encounter 3-4 cases daily out of 20-30 million requests where a 404 
error appears in the Tomcat access logs, and the corresponding call 
fails to reach the mapped servlet. Interestingly, the same calls work 
perfectly just a few milliseconds before and after on the same node. 
This inconsistency is causing significant issues, especially when 
critical API calls fail and are not automatically retried.


Is there any open issue related to this problem that we should be aware of?


None that I know of personally.

Can you post your exact Tomcat version, your  configuration 
with any secrets removed and a little more background on the type of 
traffic you are seeing (e.g. HTTP/1.1 v h2, TLS or not, etc.). Are you 
able to tell if these failed requests are part of any kind of pipelined 
requests (HTTP Keep-Alive) or h2 single channels?


Understanding the network topology may be relevant, though its unlikely 
that any lb/rp is doing this, as you can see the logs on the Tomcat 
node. But it may change the way the requests are being handled based 
upon the type of connection between the lb/rp and Tomcat.


Have you double-checked that the URIs are clean and don't contain 
anything unexpected such as lookalike characters, etc.? I suspect this 
is not an issue since you said "critical API calls fail" which leads me 
to understand that you have legitimate customers reporting these 
failures, instead of just investigating unexpected entries in your log 
files.


Is your testing environment reasonably similar to production? What would 
happen if you were to reply a whole day's worth of production-requests 
through your testing environment?


Is there any pattern whatsoever in the failed requests? If you look at 
every failed request for all time, are they randomly distributed 
throughout your URI space, or do you find that some URIs are 
over-represented in your failure data? You may have so few failures that 
you can't draw any conclusions.


-chris

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

Tomcat 9 -> Intermittent 404 (3-4 fails in 20-30 million requests daily sometimes )

[Anurag Kumar]

Hi, we are experiencing intermittent 404 errors with both GET and POST
calls. These errors are quite rare and have proven difficult to reproduce
in our testing environment. However, on our production system, we encounter
3-4 cases daily out of 20-30 million requests where a 404 error appears in
the Tomcat access logs, and the corresponding call fails to reach the
mapped servlet. Interestingly, the same calls work perfectly just a few
milliseconds before and after on the same node. This inconsistency is
causing significant issues, especially when critical API calls fail and are
not automatically retried.

Is there any open issue related to this problem that we should be aware of?


[image: image.png]


Thanks
Anurag

getting 404 after migrating app to rpm based tomcat install

[Niranjan Babu Bommu]

Can some please help me out with this?. recently we have started migrating
our application from Tomcat 8.5.49 (tar file)  to the RPM-installed Tomcat
8.5.89. We encountered a 404 error after the migration

tomcat 8.5.49 tar file installation:

TOMCAT_HOME: /deploy/software/tomcat

TOMCAT_BASE:  /deploy/software/tomcat

 webapps:

  ROOT -> 

the above config is the current one where we have running apps in dev ,stg
and prod.

tomcat 8.5.89 rpm installation

TOMCAT_HOME: /usr/share/tomcat8

( maintaining same conf dir/files including web.xml what we
have with ver 8.5.49)

TOMCAT_BASE:  /usr/share/tomcat8

 webapps:

  ROOT -> 


no errors in catalina.out and app is coming up fine and able to connect
both ports 8080 and 8443, but I do get 404 when I hit the page

*Description* The origin server did not find a current representation for
the target resource or is not willing to disclose that one exists.
-- 
*Thanks*
*Niranjan*

Re: health check return 404 after upgrade from 70 to tomcat 9.0.71

[Rui]

Hi user group:
just found open-telemetry has fixing for it:

https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/instrumentation/tomcat/tomcat-common/javaagent/src/main/java/io/opentelemetry/javaagent/instrumentation/tomcat/common/TomcatHelper.java#L71


```
 static String messageBytesToString(MessageBytes messageBytes) {
// on tomcat 10.1.0 MessageBytes.toString() has a side effect. Calling
it caches the string
// value and changes type of the MessageBytes from T_BYTES to T_STR
which breaks request
// processing in CoyoteAdapter.postParseRequest when it is called on
MessageBytes from
// request.requestURI().
if (messageBytes.getType() == MessageBytes.T_BYTES) {
  return messageBytes.getByteChunk().toString();
}
return messageBytes.toString();
  }
}
```

so I will update our telemetry-agent first
thanks!
Zhou Rui

On Sat, 18 Mar 2023 at 11:33, Rui  wrote:

> Hi Mark
>
> I can't find any Valve setting in the spring boot application(search by
> valve), would you mind sharing more info?
>
> Regarding the mb state and debugging, yes aware that my local intellij
> debugger could change the mb state, so in the the debug lib I call
> mb.getType() only
>
> I got more interesting logs today:
>
> step 1. a stack trace before it hits CoyoteAdapter.java#L677
> <https://github.com/apache/tomcat/blob/9.0.71/java/org/apache/catalina/connector/CoyoteAdapter.java#L677>
>
> ``` I type manually, can't copy it
> mb.toString()
>
> io.opentelemetry.javaagent.instrumentation.tomcat.common.TomcatHttpAttributesGetter.target(TomcatHttpAttributesGetter.java:26)
> ...
> ```
> refer to
>
> https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/instrumentation/tomcat/tomcat-common/javaagent/src/main/java/io/opentelemetry/javaagent/instrumentation/tomcat/common/TomcatHttpAttributesGetter.java#L28
>
> so the thing is telemetry-agent adds instrumentation code to call
> mb.toString() before it hits tomcat, which will change mb type(to T_STR)
>
>
> step 2.
> https://github.com/apache/tomcat/blob/9.0.71/java/org/apache/catalina/connector/CoyoteAdapter.java#L677
> mb type was changed at step1 so the following processing is wrong.
>
> Questions:
> 1. In mb.toString() it will change the type to (T_STR), is it a right
> approach?(compare with 9.0.70)
> 2. It may not be tomcat bug, but I feel a bit confused. The type will be
> changed to T_STR implicitly when call mb.toString(), it is kind of API
> change will impact 3rd libs such as open-telemetry?
> 3.  what is your suggestion to solve this issue?
>
>
> thanks
> Zhou Rui
>
> On Fri, 17 Mar 2023 at 22:41, Mark Thomas  wrote:
>
>> On 17/03/2023 14:27, Rui wrote:
>> > Hi user group:
>> >
>> > I added some debug info to the 9.0.71 baseline
>> >
>> > from the logs it hit this (supposed not inn 9.0.70)
>> >
>> https://github.com/apache/tomcat/blob/9.0.71/java/org/apache/catalina/connector/CoyoteAdapter.java#L677
>>
>> That suggests you are using the Rewrite Valve? Is that correct?
>>
>> If so, that suggests that whatever is going wrong, is going wrong in
>> that Valve.
>>
>> If not, it is likely that your debugging is corrupting the state of the
>> MessageByte instances. You need to be really careful when logging values
>> from them.
>>
>> Mark
>>
>> >
>> > means undecodedURI type is T_CHARS or T_STR, however, decodedURI type is
>> > T_NULL at this time,
>> > so decodedURI.toChars();  actually will recycle its buffer.
>> >
>> > I can reproduce it locally with debug mode, but don't know how
>> reproduce it
>> > in the company EKS cluster
>> >
>> > thanks.
>> > Zhou Rui
>> >
>> >
>> >
>> > On Fri, 17 Mar 2023 at 00:50, Rui  wrote:
>> >
>> >> I did some tests with several different commits in 9.0.71, I think my
>> >> issue is caused by this
>> >>
>> >>
>> https://github.com/apache/tomcat/commit/10a1a6d46d952bab4dfde44c3c0de12b0330da79
>> >> the "toBytesSimple" change has not been added to the repo yet, so the
>> >> change in 9.073 doesn't solve the problem.
>> >> Next I will go through these codes, but any clue?
>> >>
>> >> thanks
>> >> Zhou Rui
>> >>
>> >>
>> >> On Tue, 7 Mar 2023 at 00:34, Mark Thomas  wrote:
>> >>
>> >>> On 25/02/2023 17:57, Mark Thomas wrote:
>> >>>>
>> >>>>
>> >>>> On 25/02/2023 15:47, Rui wrote:
>> >>>>&g

Re: health check return 404 after upgrade from 70 to tomcat 9.0.71

[Rui]

Hi Mark

I can't find any Valve setting in the spring boot application(search by
valve), would you mind sharing more info?

Regarding the mb state and debugging, yes aware that my local intellij
debugger could change the mb state, so in the the debug lib I call
mb.getType() only

I got more interesting logs today:

step 1. a stack trace before it hits CoyoteAdapter.java#L677
<https://github.com/apache/tomcat/blob/9.0.71/java/org/apache/catalina/connector/CoyoteAdapter.java#L677>

``` I type manually, can't copy it
mb.toString()
io.opentelemetry.javaagent.instrumentation.tomcat.common.TomcatHttpAttributesGetter.target(TomcatHttpAttributesGetter.java:26)
...
```
refer to
https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/instrumentation/tomcat/tomcat-common/javaagent/src/main/java/io/opentelemetry/javaagent/instrumentation/tomcat/common/TomcatHttpAttributesGetter.java#L28

so the thing is telemetry-agent adds instrumentation code to call
mb.toString() before it hits tomcat, which will change mb type(to T_STR)


step 2.
https://github.com/apache/tomcat/blob/9.0.71/java/org/apache/catalina/connector/CoyoteAdapter.java#L677
mb type was changed at step1 so the following processing is wrong.

Questions:
1. In mb.toString() it will change the type to (T_STR), is it a right
approach?(compare with 9.0.70)
2. It may not be tomcat bug, but I feel a bit confused. The type will be
changed to T_STR implicitly when call mb.toString(), it is kind of API
change will impact 3rd libs such as open-telemetry?
3.  what is your suggestion to solve this issue?


thanks
Zhou Rui

On Fri, 17 Mar 2023 at 22:41, Mark Thomas  wrote:

> On 17/03/2023 14:27, Rui wrote:
> > Hi user group:
> >
> > I added some debug info to the 9.0.71 baseline
> >
> > from the logs it hit this (supposed not inn 9.0.70)
> >
> https://github.com/apache/tomcat/blob/9.0.71/java/org/apache/catalina/connector/CoyoteAdapter.java#L677
>
> That suggests you are using the Rewrite Valve? Is that correct?
>
> If so, that suggests that whatever is going wrong, is going wrong in
> that Valve.
>
> If not, it is likely that your debugging is corrupting the state of the
> MessageByte instances. You need to be really careful when logging values
> from them.
>
> Mark
>
> >
> > means undecodedURI type is T_CHARS or T_STR, however, decodedURI type is
> > T_NULL at this time,
> > so decodedURI.toChars();  actually will recycle its buffer.
> >
> > I can reproduce it locally with debug mode, but don't know how reproduce
> it
> > in the company EKS cluster
> >
> > thanks.
> > Zhou Rui
> >
> >
> >
> > On Fri, 17 Mar 2023 at 00:50, Rui  wrote:
> >
> >> I did some tests with several different commits in 9.0.71, I think my
> >> issue is caused by this
> >>
> >>
> https://github.com/apache/tomcat/commit/10a1a6d46d952bab4dfde44c3c0de12b0330da79
> >> the "toBytesSimple" change has not been added to the repo yet, so the
> >> change in 9.073 doesn't solve the problem.
> >> Next I will go through these codes, but any clue?
> >>
> >> thanks
> >> Zhou Rui
> >>
> >>
> >> On Tue, 7 Mar 2023 at 00:34, Mark Thomas  wrote:
> >>
> >>> On 25/02/2023 17:57, Mark Thomas wrote:
> >>>>
> >>>>
> >>>> On 25/02/2023 15:47, Rui wrote:
> >>>>> Hi
> >>>>> recently upgraded tomcat to 9.0.71 from 9.0.70
> >>>>> but saw 404 in our EKS cluster(with istio installed)
> >>>>>
> >>>>> Received [GET /actuator HTTP/1.1
> >>>>> Host: x:8079
> >>>>> User-Agent: kube-probe/1.23+
> >>>>> Accept: */*
> >>>>> Connection: close
> >>>>> Accept-Encoding: gzip
> >>>>> ]
> >>>>> Incoming request /health with originalRemoteAddr 
> >>>>>
> >>>>> in 9.0.70 I can see the below following message but not in 9.0.71
> >>>>> o.a.c.authenticator.AuthenticatorBase: Security checking request
> >>> GET
> >>>>> /health
> >>>>>
> >>>>> seems the processing has stopped somewhere and the pod health check
> >>>>> didn't
> >>>>> pass.
> >>>>>
> >>>>> I also noticed there was also a 404 issue but don't know if it is
> >>>>> relevant.
> >>>>> https://lists.apache.org/thread/gr814rmrlbk9rrqxqjrh4p3x0bfvv1g9
> >>>>>
> >>>>> I have tested it locally with curl or jmet

Re: health check return 404 after upgrade from 70 to tomcat 9.0.71

[Mark Thomas]

On 17/03/2023 14:27, Rui wrote:

Hi user group:

I added some debug info to the 9.0.71 baseline

from the logs it hit this (supposed not inn 9.0.70)
https://github.com/apache/tomcat/blob/9.0.71/java/org/apache/catalina/connector/CoyoteAdapter.java#L677


That suggests you are using the Rewrite Valve? Is that correct?

If so, that suggests that whatever is going wrong, is going wrong in 
that Valve.


If not, it is likely that your debugging is corrupting the state of the 
MessageByte instances. You need to be really careful when logging values 
from them.


Mark



means undecodedURI type is T_CHARS or T_STR, however, decodedURI type is
T_NULL at this time,
so decodedURI.toChars();  actually will recycle its buffer.

I can reproduce it locally with debug mode, but don't know how reproduce it
in the company EKS cluster

thanks.
Zhou Rui



On Fri, 17 Mar 2023 at 00:50, Rui  wrote:


I did some tests with several different commits in 9.0.71, I think my
issue is caused by this

https://github.com/apache/tomcat/commit/10a1a6d46d952bab4dfde44c3c0de12b0330da79
the "toBytesSimple" change has not been added to the repo yet, so the
change in 9.073 doesn't solve the problem.
Next I will go through these codes, but any clue?

thanks
Zhou Rui


On Tue, 7 Mar 2023 at 00:34, Mark Thomas  wrote:


On 25/02/2023 17:57, Mark Thomas wrote:



On 25/02/2023 15:47, Rui wrote:

Hi
recently upgraded tomcat to 9.0.71 from 9.0.70
but saw 404 in our EKS cluster(with istio installed)

Received [GET /actuator HTTP/1.1
Host: x:8079
User-Agent: kube-probe/1.23+
Accept: */*
Connection: close
Accept-Encoding: gzip
]
Incoming request /health with originalRemoteAddr 

in 9.0.70 I can see the below following message but not in 9.0.71
o.a.c.authenticator.AuthenticatorBase: Security checking request

GET

/health

seems the processing has stopped somewhere and the pod health check
didn't
pass.

I also noticed there was also a 404 issue but don't know if it is
relevant.
https://lists.apache.org/thread/gr814rmrlbk9rrqxqjrh4p3x0bfvv1g9

I have tested it locally with curl or jmeter, but can't reproduce
the problem.

but when I step by step debug the spring app, I found the undecodedURI
type
is T_STR
in CoyoteAdapter.java(in 70 it supposed to be T_BYTES), then
decodedURI is
uninitialized and the uri can't find the mapping in internalMap of
Mapper.java, which will cause 404(guess it thinks the uri is malformed)

MessageBytes decodedURI = req.decodedURI();

if (undecodedURI.getType() == MessageBytes.T_BYTES) {
  // Copy the raw URI to the decodedURI
  decodedURI.duplicate(undecodedURI);


404 example: (when I debug step by step to check unndecodedURI)

curl http://localhost:8080/actuator

HTTP Status 404 – Not
Foundbody
{font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b
{color:white;background-color:#525D76;} h1 {font-size:22px;} h2
{font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a
{color:black;}
.line

</pre></blockquote></blockquote><pre style="margin: 0em;">
{height:1px;background-color:#525D76;border:none;}HTTP

Status 404 – Not Found%


However, it runs well without breakpoint! I am quite confused...my
intellij
has problem?
but anyway, summary:
   9.0.69 and 70 are good in the AWS/EKS(kubernetes) cluster with istio
9.0.71 and 72 return 404 when health check by the EKS cluster.


Looks like an instance of:
https://bz.apache.org/bugzilla/show_bug.cgi?id=66488


If not that then maybe

https://bz.apache.org/bugzilla/show_bug.cgi?id=66512

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: health check return 404 after upgrade from 70 to tomcat 9.0.71

[Rui]

Hi user group:

I added some debug info to the 9.0.71 baseline

from the logs it hit this (supposed not inn 9.0.70)
https://github.com/apache/tomcat/blob/9.0.71/java/org/apache/catalina/connector/CoyoteAdapter.java#L677

means undecodedURI type is T_CHARS or T_STR, however, decodedURI type is
T_NULL at this time,
so decodedURI.toChars();  actually will recycle its buffer.

I can reproduce it locally with debug mode, but don't know how reproduce it
in the company EKS cluster

thanks.
Zhou Rui



On Fri, 17 Mar 2023 at 00:50, Rui  wrote:

> I did some tests with several different commits in 9.0.71, I think my
> issue is caused by this
>
> https://github.com/apache/tomcat/commit/10a1a6d46d952bab4dfde44c3c0de12b0330da79
> the "toBytesSimple" change has not been added to the repo yet, so the
> change in 9.073 doesn't solve the problem.
> Next I will go through these codes, but any clue?
>
> thanks
> Zhou Rui
>
>
> On Tue, 7 Mar 2023 at 00:34, Mark Thomas  wrote:
>
>> On 25/02/2023 17:57, Mark Thomas wrote:
>> >
>> >
>> > On 25/02/2023 15:47, Rui wrote:
>> >> Hi
>> >> recently upgraded tomcat to 9.0.71 from 9.0.70
>> >> but saw 404 in our EKS cluster(with istio installed)
>> >>
>> >> Received [GET /actuator HTTP/1.1
>> >> Host: x:8079
>> >> User-Agent: kube-probe/1.23+
>> >> Accept: */*
>> >> Connection: close
>> >> Accept-Encoding: gzip
>> >> ]
>> >> Incoming request /health with originalRemoteAddr 
>> >>
>> >> in 9.0.70 I can see the below following message but not in 9.0.71
>> >> o.a.c.authenticator.AuthenticatorBase: Security checking request
>> GET
>> >> /health
>> >>
>> >> seems the processing has stopped somewhere and the pod health check
>> >> didn't
>> >> pass.
>> >>
>> >> I also noticed there was also a 404 issue but don't know if it is
>> >> relevant.
>> >> https://lists.apache.org/thread/gr814rmrlbk9rrqxqjrh4p3x0bfvv1g9
>> >>
>> >> I have tested it locally with curl or jmeter, but can't reproduce
>> >> the problem.
>> >>
>> >> but when I step by step debug the spring app, I found the undecodedURI
>> >> type
>> >> is T_STR
>> >> in CoyoteAdapter.java(in 70 it supposed to be T_BYTES), then
>> >> decodedURI is
>> >> uninitialized and the uri can't find the mapping in internalMap of
>> >> Mapper.java, which will cause 404(guess it thinks the uri is malformed)
>> >>
>> >> MessageBytes decodedURI = req.decodedURI();
>> >>
>> >> if (undecodedURI.getType() == MessageBytes.T_BYTES) {
>> >>  // Copy the raw URI to the decodedURI
>> >>  decodedURI.duplicate(undecodedURI);
>> >>
>> >>
>> >> 404 example: (when I debug step by step to check unndecodedURI)
>> >>
>> >> curl http://localhost:8080/actuator
>> >>
>> >> HTTP Status 404 – Not
>> >> Foundbody
>> >> {font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b
>> >> {color:white;background-color:#525D76;} h1 {font-size:22px;} h2
>> >> {font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a
>> >> {color:black;}
>> >> .line
>> >>
>> {height:1px;background-color:#525D76;border:none;}HTTP
>> >> Status 404 – Not Found%
>> >>
>> >>
>> >> However, it runs well without breakpoint! I am quite confused...my
>> >> intellij
>> >> has problem?
>> >> but anyway, summary:
>> >>   9.0.69 and 70 are good in the AWS/EKS(kubernetes) cluster with istio
>> >> 9.0.71 and 72 return 404 when health check by the EKS cluster.
>> >
>> > Looks like an instance of:
>> > https://bz.apache.org/bugzilla/show_bug.cgi?id=66488
>>
>> If not that then maybe
>>
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=66512
>>
>> Mark
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>

Re: health check return 404 after upgrade from 70 to tomcat 9.0.71

[Rui]

I did some tests with several different commits in 9.0.71, I think my issue
is caused by this
https://github.com/apache/tomcat/commit/10a1a6d46d952bab4dfde44c3c0de12b0330da79
the "toBytesSimple" change has not been added to the repo yet, so the
change in 9.073 doesn't solve the problem.
Next I will go through these codes, but any clue?

thanks
Zhou Rui


On Tue, 7 Mar 2023 at 00:34, Mark Thomas  wrote:

> On 25/02/2023 17:57, Mark Thomas wrote:
> >
> >
> > On 25/02/2023 15:47, Rui wrote:
> >> Hi
> >> recently upgraded tomcat to 9.0.71 from 9.0.70
> >> but saw 404 in our EKS cluster(with istio installed)
> >>
> >> Received [GET /actuator HTTP/1.1
> >> Host: x:8079
> >> User-Agent: kube-probe/1.23+
> >> Accept: */*
> >> Connection: close
> >> Accept-Encoding: gzip
> >> ]
> >> Incoming request /health with originalRemoteAddr 
> >>
> >> in 9.0.70 I can see the below following message but not in 9.0.71
> >> o.a.c.authenticator.AuthenticatorBase: Security checking request GET
> >> /health
> >>
> >> seems the processing has stopped somewhere and the pod health check
> >> didn't
> >> pass.
> >>
> >> I also noticed there was also a 404 issue but don't know if it is
> >> relevant.
> >> https://lists.apache.org/thread/gr814rmrlbk9rrqxqjrh4p3x0bfvv1g9
> >>
> >> I have tested it locally with curl or jmeter, but can't reproduce
> >> the problem.
> >>
> >> but when I step by step debug the spring app, I found the undecodedURI
> >> type
> >> is T_STR
> >> in CoyoteAdapter.java(in 70 it supposed to be T_BYTES), then
> >> decodedURI is
> >> uninitialized and the uri can't find the mapping in internalMap of
> >> Mapper.java, which will cause 404(guess it thinks the uri is malformed)
> >>
> >> MessageBytes decodedURI = req.decodedURI();
> >>
> >> if (undecodedURI.getType() == MessageBytes.T_BYTES) {
> >>  // Copy the raw URI to the decodedURI
> >>  decodedURI.duplicate(undecodedURI);
> >>
> >>
> >> 404 example: (when I debug step by step to check unndecodedURI)
> >>
> >> curl http://localhost:8080/actuator
> >>
> >> HTTP Status 404 – Not
> >> Foundbody
> >> {font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b
> >> {color:white;background-color:#525D76;} h1 {font-size:22px;} h2
> >> {font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a
> >> {color:black;}
> >> .line
> >>
> {height:1px;background-color:#525D76;border:none;}HTTP
> >> Status 404 – Not Found%
> >>
> >>
> >> However, it runs well without breakpoint! I am quite confused...my
> >> intellij
> >> has problem?
> >> but anyway, summary:
> >>   9.0.69 and 70 are good in the AWS/EKS(kubernetes) cluster with istio
> >> 9.0.71 and 72 return 404 when health check by the EKS cluster.
> >
> > Looks like an instance of:
> > https://bz.apache.org/bugzilla/show_bug.cgi?id=66488
>
> If not that then maybe
>
> https://bz.apache.org/bugzilla/show_bug.cgi?id=66512
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

RE: health check return 404 after upgrade from 70 to tomcat 9.0.71

[jonmcalexander]

> -Original Message-
> From: Chuck Caldarale 
> Sent: Monday, March 6, 2023 1:12 PM
> To: Tomcat Users List 
> Subject: Re: health check return 404 after upgrade from 70 to tomcat 9.0.71
> 
> 
> > On Mar 6, 2023, at 12:03, 
>  wrote:
> >
> > I believe we may have figured out what was causing the issue, but not why
> it was causing it.
> >
> > In the mod-proxy-http configuration for the balancer, we had been using
> the fully qualified host name in the balancer url. When we switched to IP
> address, things got tremendously faster to the point we aren't seeing the
> health check fail any longer. What is perplexing is why removing a simple DNS
> lookup by going from host name to IP address had such a dramatic affect.  Is
> this something that adding ProxyHost and ProxyPort to the connector would
> possibly cure? We have not tried that currently.
> 
> Once upon a time (before I retired), we had slow DNS lookups due to a
> misconfigured /etc/resolv.conf file still including a disabled DNS box as the
> first in the list. Might want to check the DNS configurations on the systems 
> of
> interest and insure that all listed DNS boxes are functional.
> 
>   - Chuck
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org


Thank you Chuck!


Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com
This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.


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

Re: health check return 404 after upgrade from 70 to tomcat 9.0.71

[Chuck Caldarale]

> On Mar 6, 2023, at 12:03,  
>  wrote:
> 
> I believe we may have figured out what was causing the issue, but not why it 
> was causing it.
> 
> In the mod-proxy-http configuration for the balancer, we had been using the 
> fully qualified host name in the balancer url. When we switched to IP 
> address, things got tremendously faster to the point we aren't seeing the 
> health check fail any longer. What is perplexing is why removing a simple DNS 
> lookup by going from host name to IP address had such a dramatic affect.  Is 
> this something that adding ProxyHost and ProxyPort to the connector would 
> possibly cure? We have not tried that currently.

Once upon a time (before I retired), we had slow DNS lookups due to a 
misconfigured /etc/resolv.conf file still including a disabled DNS box as the 
first in the list. Might want to check the DNS configurations on the systems of 
interest and insure that all listed DNS boxes are functional.

  - Chuck


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

RE: health check return 404 after upgrade from 70 to tomcat 9.0.71

[jonmcalexander]

> -Original Message-
> From: Mark Thomas 
> Sent: Monday, March 6, 2023 10:34 AM
> To: users@tomcat.apache.org
> Subject: Re: health check return 404 after upgrade from 70 to tomcat 9.0.71
> 
> On 25/02/2023 17:57, Mark Thomas wrote:
> >
> >
> > On 25/02/2023 15:47, Rui wrote:
> >> Hi
> >> recently upgraded tomcat to 9.0.71 from 9.0.70 but saw 404 in our EKS
> >> cluster(with istio installed)
> >>
> >> Received [GET /actuator HTTP/1.1
> >> Host: x:8079
> >> User-Agent: kube-probe/1.23+
> >> Accept: */*
> >> Connection: close
> >> Accept-Encoding: gzip
> >> ]
> >> Incoming request /health with originalRemoteAddr 
> >>
> >> in 9.0.70 I can see the below following message but not in 9.0.71
> >> o.a.c.authenticator.AuthenticatorBase    : Security checking request
> >> GET /health
> >>
> >> seems the processing has stopped somewhere and the pod health check
> >> didn't pass.
> >>
> >> I also noticed there was also a 404 issue but don't know if it is
> >> relevant.
> >> https://urldefense.com/v3/__https://lists.apache.org/thread/gr814rmrl
> >> bk9rrqxqjrh4p3x0bfvv1g9__;!!F9svGWnIaVPGSwU!uiVBZpR54vzNpwI-
> 1lyRTgM4j
> >> KczN4Bobrx34KVhfSRZo-W3EsxLU7epxoIiW_-
> gA2CtJmE_dFUEWwJPZkCMDg$
> >>
> >> I have tested it locally with curl or jmeter, but can't reproduce the
> >> problem.
> >>
> >> but when I step by step debug the spring app, I found the
> >> undecodedURI type is T_STR in CoyoteAdapter.java(in 70 it supposed to
> >> be T_BYTES), then decodedURI is uninitialized and the uri can't find
> >> the mapping in internalMap of Mapper.java, which will cause 404(guess
> >> it thinks the uri is malformed)
> >>
> >> MessageBytes decodedURI = req.decodedURI();
> >>
> >> if (undecodedURI.getType() == MessageBytes.T_BYTES) {
> >>      // Copy the raw URI to the decodedURI
> >>  decodedURI.duplicate(undecodedURI);
> >>
> >>
> >> 404 example: (when I debug step by step to check unndecodedURI)
> >>
> >> curl
> >>
> https://urldefense.com/v3/__http://localhost:8080/actuator__;!!F9svGW
> >> nIaVPGSwU!uiVBZpR54vzNpwI-1lyRTgM4jKczN4Bobrx34KVhfSRZo-
> W3EsxLU7epxoI
> >> iW_-gA2CtJmE_dFUEWwKRB2lDBg$
> >>
> >> HTTP Status 404 – Not
> >> Foundbody
> >> {font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b
> >> {color:white;background-color:#525D76;} h1 {font-size:22px;} h2
> >> {font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a
> >> {color:black;} .line
> >> {height:1px;background-
> color:#525D76;border:none;} >> y>HTTP Status 404 – Not Found%
> >>
> >>
> >> However, it runs well without breakpoint! I am quite confused...my
> >> intellij has problem?
> >> but anyway, summary:
> >>   9.0.69 and 70 are good in the AWS/EKS(kubernetes) cluster with
> >> istio
> >> 9.0.71 and 72 return 404 when health check by the EKS cluster.
> >
> > Looks like an instance of:
> > https://urldefense.com/v3/__https://bz.apache.org/bugzilla/show_bug.cg
> > i?id=66488__;!!F9svGWnIaVPGSwU!uiVBZpR54vzNpwI-
> 1lyRTgM4jKczN4Bobrx34KV
> > hfSRZo-W3EsxLU7epxoIiW_-gA2CtJmE_dFUEWwJcG2lXgg$
> 
> If not that then maybe
> 
> https://urldefense.com/v3/__https://bz.apache.org/bugzilla/show_bug.cgi?
> id=66512__;!!F9svGWnIaVPGSwU!uiVBZpR54vzNpwI-
> 1lyRTgM4jKczN4Bobrx34KVhfSRZo-W3EsxLU7epxoIiW_-
> gA2CtJmE_dFUEWwIhYU5xdQ$
> 
> Mark
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

I believe we may have figured out what was causing the issue, but not why it 
was causing it.

In the mod-proxy-http configuration for the balancer, we had been using the 
fully qualified host name in the balancer url. When we switched to IP address, 
things got tremendously faster to the point we aren't seeing the health check 
fail any longer. What is perplexing is why removing a simple DNS lookup by 
going from host name to IP address had such a dramatic affect.  Is this 
something that adding ProxyHost and ProxyPort to the connector would possibly 
cure? We have not tried that currently.

Thanks,

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com
This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.

Re: health check return 404 after upgrade from 70 to tomcat 9.0.71

[Mark Thomas]

On 25/02/2023 17:57, Mark Thomas wrote:



On 25/02/2023 15:47, Rui wrote:

Hi
recently upgraded tomcat to 9.0.71 from 9.0.70
but saw 404 in our EKS cluster(with istio installed)

Received [GET /actuator HTTP/1.1
Host: x:8079
User-Agent: kube-probe/1.23+
Accept: */*
Connection: close
Accept-Encoding: gzip
]
Incoming request /health with originalRemoteAddr 

in 9.0.70 I can see the below following message but not in 9.0.71
o.a.c.authenticator.AuthenticatorBase    : Security checking request GET
/health

seems the processing has stopped somewhere and the pod health check 
didn't

pass.

I also noticed there was also a 404 issue but don't know if it is 
relevant.

https://lists.apache.org/thread/gr814rmrlbk9rrqxqjrh4p3x0bfvv1g9

I have tested it locally with curl or jmeter, but can't reproduce
the problem.

but when I step by step debug the spring app, I found the undecodedURI 
type

is T_STR
in CoyoteAdapter.java(in 70 it supposed to be T_BYTES), then 
decodedURI is

uninitialized and the uri can't find the mapping in internalMap of
Mapper.java, which will cause 404(guess it thinks the uri is malformed)

MessageBytes decodedURI = req.decodedURI();

if (undecodedURI.getType() == MessageBytes.T_BYTES) {
 // Copy the raw URI to the decodedURI
 decodedURI.duplicate(undecodedURI);


404 example: (when I debug step by step to check unndecodedURI)

curl http://localhost:8080/actuator

HTTP Status 404 – Not
Foundbody
{font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b
{color:white;background-color:#525D76;} h1 {font-size:22px;} h2
</pre><tt>{font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a 
</tt><tt>{color:black;}
</tt><pre style="margin: 0em;">
.line
{height:1px;background-color:#525D76;border:none;}HTTP
Status 404 – Not Found%


However, it runs well without breakpoint! I am quite confused...my 
intellij

has problem?
but anyway, summary:
  9.0.69 and 70 are good in the AWS/EKS(kubernetes) cluster with istio
9.0.71 and 72 return 404 when health check by the EKS cluster.


Looks like an instance of:
https://bz.apache.org/bugzilla/show_bug.cgi?id=66488


If not that then maybe

https://bz.apache.org/bugzilla/show_bug.cgi?id=66512

Mark

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

Re: health check return 404 after upgrade from 70 to tomcat 9.0.71

[Mark Thomas]

On 25/02/2023 15:47, Rui wrote:

Hi
recently upgraded tomcat to 9.0.71 from 9.0.70
but saw 404 in our EKS cluster(with istio installed)

Received [GET /actuator HTTP/1.1
Host: x:8079
User-Agent: kube-probe/1.23+
Accept: */*
Connection: close
Accept-Encoding: gzip
]
Incoming request /health with originalRemoteAddr 

in 9.0.70 I can see the below following message but not in 9.0.71
o.a.c.authenticator.AuthenticatorBase: Security checking request GET
/health

seems the processing has stopped somewhere and the pod health check didn't
pass.

I also noticed there was also a 404 issue but don't know if it is relevant.
https://lists.apache.org/thread/gr814rmrlbk9rrqxqjrh4p3x0bfvv1g9

I have tested it locally with curl or jmeter, but can't reproduce
the problem.

but when I step by step debug the spring app, I found the undecodedURI type
is T_STR
in CoyoteAdapter.java(in 70 it supposed to be T_BYTES), then decodedURI is
uninitialized and the uri can't find the mapping in internalMap of
Mapper.java, which will cause 404(guess it thinks the uri is malformed)

MessageBytes decodedURI = req.decodedURI();

if (undecodedURI.getType() == MessageBytes.T_BYTES) {
 // Copy the raw URI to the decodedURI
 decodedURI.duplicate(undecodedURI);


404 example: (when I debug step by step to check unndecodedURI)

curl http://localhost:8080/actuator

HTTP Status 404 – Not
Foundbody
{font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b
{color:white;background-color:#525D76;} h1 {font-size:22px;} h2
{font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a {color:black;}
.line
{height:1px;background-color:#525D76;border:none;}HTTP
Status 404 – Not Found%


However, it runs well without breakpoint! I am quite confused...my intellij
has problem?
but anyway, summary:
  9.0.69 and 70 are good in the AWS/EKS(kubernetes) cluster with istio
9.0.71 and 72 return 404 when health check by the EKS cluster.


Looks like an instance of:
https://bz.apache.org/bugzilla/show_bug.cgi?id=66488

Mark

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

health check return 404 after upgrade from 70 to tomcat 9.0.71

[Rui]

Hi
recently upgraded tomcat to 9.0.71 from 9.0.70
but saw 404 in our EKS cluster(with istio installed)

Received [GET /actuator HTTP/1.1
Host: x:8079
User-Agent: kube-probe/1.23+
Accept: */*
Connection: close
Accept-Encoding: gzip
]
Incoming request /health with originalRemoteAddr 

in 9.0.70 I can see the below following message but not in 9.0.71
o.a.c.authenticator.AuthenticatorBase: Security checking request GET
/health

seems the processing has stopped somewhere and the pod health check didn't
pass.

I also noticed there was also a 404 issue but don't know if it is relevant.
https://lists.apache.org/thread/gr814rmrlbk9rrqxqjrh4p3x0bfvv1g9

I have tested it locally with curl or jmeter, but can't reproduce
the problem.

but when I step by step debug the spring app, I found the undecodedURI type
is T_STR
in CoyoteAdapter.java(in 70 it supposed to be T_BYTES), then decodedURI is
uninitialized and the uri can't find the mapping in internalMap of
Mapper.java, which will cause 404(guess it thinks the uri is malformed)

MessageBytes decodedURI = req.decodedURI();

if (undecodedURI.getType() == MessageBytes.T_BYTES) {
// Copy the raw URI to the decodedURI
decodedURI.duplicate(undecodedURI);


404 example: (when I debug step by step to check unndecodedURI)

curl http://localhost:8080/actuator

HTTP Status 404 – Not
Foundbody
{font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b
{color:white;background-color:#525D76;} h1 {font-size:22px;} h2
{font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a {color:black;}
.line
{height:1px;background-color:#525D76;border:none;}HTTP
Status 404 – Not Found%


However, it runs well without breakpoint! I am quite confused...my intellij
has problem?
but anyway, summary:
 9.0.69 and 70 are good in the AWS/EKS(kubernetes) cluster with istio
9.0.71 and 72 return 404 when health check by the EKS cluster.

thanks
Zhou

Re: Tomcat 10.1.4 HTTP Status 404 and 500 Help

[John Barrow]

Mark,

Thanks for your corrections. I have updated my internal "How to" guide that
I created when I first used Tomcat to build my servlets and it appears that
some of my deductions from that initial research and "getting it to work"
were misguided.

John

On Wed, 11 Jan 2023, 09:28 Mark Thomas,  wrote:

>
>
> On 10/01/2023 22:34, John Barrow wrote:
> > Hi Anthony,
> >
> > Not an expert, but have managed to deploy simple servlets. A couple of
> > observations, not sure why using ROOT, you should have your own folder
> for
> > your application (e.g. myFirstApp\...).
>
> Not true. ROOT is an acceptable option here.
>
> > Also, I have found that the main app folder (e.g. myFirstApp) must start
> > with a lowercase letter (I don't know reason for this but have it in my
> > notes) otherwise the servlets won't be found when accessing them through
> a
> > browser.
>
> Also not true. You may be mixing the rules for Java package names with
> those for context paths.
>
> > Finally, the default install for TomCat has several example servlets
> > already written so check that they work first and then take the sources
> and
> > clone them, using them as a guide for your own servlets.
> >
> > John
> >
> > PS: Probably worth reviewing what file names you use (see your
> webapps.xml
> > file) when making public requests so as not to inadvertently offend
> anyone.
>
> +1
>
> Mark
>
> >
> > On Tue, 10 Jan 2023, 18:59 Anthony Dell'Anno,
> >  wrote:
> >
> >> Good afternoon,
> >>
> >>  I'm trying to run my first servlet on Tomcat, and am continually
> >> getting an HTTP Status 404 (I've also gotten 500 previously, with the
> root
> >> cause being an apparent compiler mismatch (it would say that it's being
> >> compiled by version 63.0, which is Java 19, but that the latest version
> >> that was currently accepted was version 59.0, or Java 15), but then
> after
> >> upgrading to JDK 19, changing the JAVA_HOME variable and trying to run,
> it
> >> would still give me the same error)?
> >>
> >>  I have my Servlet, called HelloWorldServlet, located in the
> >> "C:\apache-tomcat-10.1.4\webapps\ROOT\WEB-INF\classes\" directory, with
> the
> >> web.xml file being located outside of the classes folder, directly
> inside
> >> of the WEB-INF folder.
> >>
> >>  I've included both files. StackOverflow wasn't much help as of
> yet, so
> >> I'm hoping that the Tomcat Users community can help me solve this so
> that I
> >> can continue learning servlets. I'm working on building my own software
> >> company.
> >>
> >> Any help is appreciated.
> >>
> >> Thank you very much,
> >>
> >> Anthony Dell'Anno
> >>
> >> -
> >> 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: Tomcat 10.1.4 HTTP Status 404 and 500 Help

[Mark Thomas]

On 10/01/2023 22:34, John Barrow wrote:

Hi Anthony,

Not an expert, but have managed to deploy simple servlets. A couple of
observations, not sure why using ROOT, you should have your own folder for
your application (e.g. myFirstApp\...).


Not true. ROOT is an acceptable option here.


Also, I have found that the main app folder (e.g. myFirstApp) must start
with a lowercase letter (I don't know reason for this but have it in my
notes) otherwise the servlets won't be found when accessing them through a
browser.


Also not true. You may be mixing the rules for Java package names with 
those for context paths.



Finally, the default install for TomCat has several example servlets
already written so check that they work first and then take the sources and
clone them, using them as a guide for your own servlets.

John

PS: Probably worth reviewing what file names you use (see your webapps.xml
file) when making public requests so as not to inadvertently offend anyone.


+1

Mark



On Tue, 10 Jan 2023, 18:59 Anthony Dell'Anno,
 wrote:


Good afternoon,

 I'm trying to run my first servlet on Tomcat, and am continually
getting an HTTP Status 404 (I've also gotten 500 previously, with the root
cause being an apparent compiler mismatch (it would say that it's being
compiled by version 63.0, which is Java 19, but that the latest version
that was currently accepted was version 59.0, or Java 15), but then after
upgrading to JDK 19, changing the JAVA_HOME variable and trying to run, it
would still give me the same error)?

 I have my Servlet, called HelloWorldServlet, located in the
"C:\apache-tomcat-10.1.4\webapps\ROOT\WEB-INF\classes\" directory, with the
web.xml file being located outside of the classes folder, directly inside
of the WEB-INF folder.

 I've included both files. StackOverflow wasn't much help as of yet, so
I'm hoping that the Tomcat Users community can help me solve this so that I
can continue learning servlets. I'm working on building my own software
company.

Any help is appreciated.

Thank you very much,

Anthony Dell'Anno

-
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: Tomcat 10.1.4 HTTP Status 404 and 500 Help

[Christopher Schultz]

Anthony,

On 1/10/23 13:58, Anthony Dell'Anno wrote:

I'm trying to run my first servlet on Tomcat


Welcome!


and am continually getting an HTTP Status 404 (I've also gotten 500
previously, with the root cause being an apparent compiler mismatch
(it would say that it's being compiled by version 63.0, which is Java
19, but that the latest version that was currently accepted was
version 59.0, or Java 15), but then after upgrading to JDK 19,
changing the JAVA_HOME variable and trying to run, it would still
give me the same error)?


Any error like "Unsupported class version 63.0" or similar will be due 
to a JVM mismatch. There are three ways to correct this:


1. Compile with an earlier JVM
2. Run with a later JVM
3. Specify the target JVM with the compiler. This can be done with the 
"-target" compiler switch in modern compilers


I have my Servlet, called HelloWorldServlet, located in the 
"C:\apache-tomcat-10.1.4\webapps\ROOT\WEB-INF\classes\" directory


This isn't a good choice, but will work. I can get back to this, later. 
Is your servlet compiled into a .class file, or do you have a .java file 
in that directory (or both, which is fine)?



with the web.xml file being located outside of the classes folder,
directly inside of the WEB-INF folder.


That's where it belongs. The "ROOT" directory contains the entire web 
application, and WEB-INF is a special directory which can contain:


classes/**/*.class [classes, usually your application]
lib/*.jar [libraries, usually from elsewhere]
web.xml [the deployment descriptor]

I've included both files. StackOverflow wasn't much help as of yet, 
The mailing list often strips attachments, but your plain-text 
attachment made it through. It's much less helpful as an attachment than 
if it were inline, so I'm going to post it here so I can comment on it, 
and also so others can read it without having to detach it:


(I've performed some light editing, which I hope you'll understand.)




  
  

HelloWorldServlet
webapps.HelloXXXServlet
  

  
HelloWorldServlet

/HelloWorld

  




What is the name of the servlet class itself? You said you have a file 
in WEB-INF/classes called HelloWorldServlet. If that's the class name, 
then it should be in the file HelloWorldServlet.class. In your 
configuration, you have servlet.HelloXXXServlet which is definitely wrong.


If your class name is actually HelloXXXServlet, then you need:

  
  

HelloWorldServlet
HelloXXXServlet
  

The servlet class needs to be the "fully qualified name" of the class, 
which will be the package name (which is nothing in your case) followed 
by a period (if it's in a package, which it isn't) followed by the short 
name of the class (HelloXXXServlet).


The "webapps." was completely incorrect, and it's not clear to me 
exactly what the class name actually is, but I think you should be able 
to get it from here.


The  is something you can make-up and is only used within 
web.xml for the purposes of defining a  and then mapping it 
later in  (and other things, actually, but you aren't 
working with any of those quite yet).


Back to the "don't put your files into WEB-INF/classes" comment I made 
above: it's a good idea to put all of your code into "packages". In 
Java, that means:


1. Putting your class source e.g. HelloXXXServlet.java into a directory 
which matches the package. So if your package will be 
"anthony.dellanno", then you need to have your file in 
src/anthony/dellanno/HelloXXXServlet.java. When compiled, this file 
needs to go into WEB-INF/classes/anthony/dellanno/HelloXXXSServlet.class


2. In your .java file, you need to add at this at the top of the file:

package anthony.dellanno;

Once you do that, you'll change the "fully qualified class name" in 
web.xml to this:


  
HelloWorldServlet
anthony.dellanno.HelloXXXServlet
  

And everything else is the same.


so I'm hoping that the Tomcat Users community can help me solve this
so that I can continue learning servlets. I'm working on building my
own software  company.
I highly recommend that anyone working with Java Servlets actually read 
the Java Servlet Specification -- whatever version makes sense for you 
to read. Almost any of them would be good, since there is little change 
between versions for the most part.


Nick Williams wrote a comprehensive (and I mean comprehensive!) book in 
2014 which – despite its age (9 years ago) – is still entirely relevant. 
It's called Professional Java for Web Applications. It guides you 
through these basics and goes all the way up through databases, 
WebSocket, and using the Spring Framework (which he favors in the book; 
other frameworks are available as well).


You can also probably find something similar as your local library if 
you don't want to pay $50 for a dead tree that takes up space on your 
shelf forever.


Hope that he

Re: Tomcat 10.1.4 HTTP Status 404 and 500 Help

[John Barrow]

Hi Anthony,

Not an expert, but have managed to deploy simple servlets. A couple of
observations, not sure why using ROOT, you should have your own folder for
your application (e.g. myFirstApp\...).

Also, I have found that the main app folder (e.g. myFirstApp) must start
with a lowercase letter (I don't know reason for this but have it in my
notes) otherwise the servlets won't be found when accessing them through a
browser.

Finally, the default install for TomCat has several example servlets
already written so check that they work first and then take the sources and
clone them, using them as a guide for your own servlets.

John

PS: Probably worth reviewing what file names you use (see your webapps.xml
file) when making public requests so as not to inadvertently offend anyone.

On Tue, 10 Jan 2023, 18:59 Anthony Dell'Anno,
 wrote:

> Good afternoon,
>
> I'm trying to run my first servlet on Tomcat, and am continually
> getting an HTTP Status 404 (I've also gotten 500 previously, with the root
> cause being an apparent compiler mismatch (it would say that it's being
> compiled by version 63.0, which is Java 19, but that the latest version
> that was currently accepted was version 59.0, or Java 15), but then after
> upgrading to JDK 19, changing the JAVA_HOME variable and trying to run, it
> would still give me the same error)?
>
> I have my Servlet, called HelloWorldServlet, located in the
> "C:\apache-tomcat-10.1.4\webapps\ROOT\WEB-INF\classes\" directory, with the
> web.xml file being located outside of the classes folder, directly inside
> of the WEB-INF folder.
>
> I've included both files. StackOverflow wasn't much help as of yet, so
> I'm hoping that the Tomcat Users community can help me solve this so that I
> can continue learning servlets. I'm working on building my own software
> company.
>
> Any help is appreciated.
>
> Thank you very much,
>
> Anthony Dell'Anno
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

Tomcat 10.1.4 HTTP Status 404 and 500 Help

[Anthony Dell'Anno]

Good afternoon, 
    I'm trying to run my first servlet on Tomcat, and am continually getting an 
HTTP Status 404 (I've also gotten 500 previously, with the root cause being an 
apparent compiler mismatch (it would say that it's being compiled by version 
63.0, which is Java 19, but that the latest version that was currently accepted 
was version 59.0, or Java 15), but then after upgrading to JDK 19, changing the 
JAVA_HOME variable and trying to run, it would still give me the same error)?

I have my Servlet, called HelloWorldServlet, located in the 
"C:\apache-tomcat-10.1.4\webapps\ROOT\WEB-INF\classes\" directory, with the 
web.xml file being located outside of the classes folder, directly inside of 
the WEB-INF folder.
    I've included both files. StackOverflow wasn't much help as of yet, so I'm 
hoping that the Tomcat Users community can help me solve this so that I can 
continue learning servlets. I'm working on building my own software  company.

Any help is appreciated.
Thank you very much,
Anthony Dell'Anno 

	 
	
		 
		
			HelloWorldServlet 
			webapps.HelloMotherFuckerServlet 
			
		 
		
		 
		
			HelloWorldServlet 
			/HelloWorld 
			
			
			
	 
	

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

Re: Apache Tomcat started, but error 404

[Rob Sargent]

> On Oct 24, 2022, at 8:36 AM, Christopher Schultz 
>  wrote:
> 
> Darious,
> 
> On 10/24/22 04:10, Strib wrote:
>> Due to the security echelon of the network, I can not send the entire
>> stacktrace.
>> However, I can say that it also states the web app archives are not
>> starting. (IllegalStateException: Error starting child).
>> Prominent "caused by" lines state bean creation errors, or instantiating
>> [org.grails.orm.hibernate.HibernateDatastore]: Constructor threw exception;
>> nested exception is
>> org.hibernate.tool.schema.extract.spi.SchemaExtractionException...
> 
> This could be almost anything.
> 
> Tomcat does not package Hibernate, so this is something your application is 
> trying to do. Maybe there is an error extracting a schema or something?
> 
> If you can't share the stack trace with this community, than this community 
> will be unable to help you. You will have to get help from internal corporate 
> resources.
> 
> -chris

Two likely places to look: 1) Connectivity to the database 2)permissions within 
the db server.   Both should write in the server’s log and the latter should 
report in the app’s log.

Re: Apache Tomcat started, but error 404

[Christopher Schultz]

Darious,

On 10/24/22 04:10, Strib wrote:

Due to the security echelon of the network, I can not send the entire
stacktrace.

However, I can say that it also states the web app archives are not
starting. (IllegalStateException: Error starting child).
Prominent "caused by" lines state bean creation errors, or instantiating
[org.grails.orm.hibernate.HibernateDatastore]: Constructor threw exception;
nested exception is
org.hibernate.tool.schema.extract.spi.SchemaExtractionException...


This could be almost anything.

Tomcat does not package Hibernate, so this is something your application 
is trying to do. Maybe there is an error extracting a schema or something?


If you can't share the stack trace with this community, than this 
community will be unable to help you. You will have to get help from 
internal corporate resources.


-chris


On Mon, Oct 24, 2022 at 4:31 PM Mark Thomas  wrote:


On 24/10/2022 08:01, Strib wrote:

Hello and thank you,

The error message reads as follows:
'org.apache.catalina.LifecycleException: Failed to start component


[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/APPWARFILE]]'

And the rest of that message? What does the stack trace show?

There may also be earlier errors in the logs that are relevant.

Mark



There are two app files trying to start, and both are getting the same
error. The weird part is, these app packages were not touched since

before

the summer. Server patches have happened since, but this is the first

month

where Tomcat is doing this So, two key notes:
1: app packages have not been changed.
2: hot and warm servers have been patched, but only hot servers received
this Tomcat error. This is the first month I've seen Tomcat not start
properly, which makes me believe it's Tomcat.
Also, just FYI, this is for Tomcat 8.

Very respectfully,
Darious


On Mon, Oct 24, 2022 at 3:28 PM Thomas Hoffmann (Speed4Trade GmbH)
 wrote:


Hello,


-Ursprüngliche Nachricht-
Von: Strib 
Gesendet: Montag, 24. Oktober 2022 08:10
An: users@tomcat.apache.org
Betreff: Apache Tomcat started, but error 404

Hello, trying to see if anyone else had this issue. After a reboot of

hot and

warm servers, my sites using Tomcat throws the error 404 only on the

hot

servers. I've stopped and started Tomcat services, nothing. In the

logs,

there

were 2 errors. One was Catalina. But even though the error happened on

hot

and warm servers, warm sites are still working, so I'm thinking that's

not it. The

other error on the hot servers says startup error. Is it just luck of

the draw, of

starting/stopping Tomcat services?
Is it something else, entirely? Frustrating that Tomcat does not have a

UI to

make this easier. Thanks in advance.

Very respectfully,
Darious


Could you past the error message about startup issue?
404 sounds like your application failed to start but Tomcat is running.
So it might be an issue with the application.
In the log files there are usually information about the reason.

Greetings, Thomas





-
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: Apache Tomcat started, but error 404

[Christopher Schultz]

Darious,

On 10/24/22 02:50, Strib wrote:

Hello and thank you,

The error message reads as follows:
'org.apache.catalina.LifecycleException: Failed to start component
[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/APPWARFILE]]'
There are two app files trying to start, and both are getting the same
error. The weird part is, these app packages were not touched since before
the summer. Server patches have happened since, but this is the first month
where Tomcat is doing this So, two key notes:
1: app packages have not been changed.
2: hot and warm servers have been patched, but only hot servers received
this Tomcat error. This is the first month I've seen Tomcat not start
properly, which makes me believe it's Tomcat.
Also, just FYI, this is for Tomcat 8.


So... "nothing" has changed except for "server patches" and now you see 
errors. So your immediate assumption is that Tomcat is suddenly failing?


I'm sure eventually you'll provide evidence and we'll get to the bottom 
of the problem, but right now your report amounts to:


"My stuff isn't working. Help."

We can't help without any information.

-chris


On Mon, Oct 24, 2022 at 3:28 PM Thomas Hoffmann (Speed4Trade GmbH)
 wrote:


Hello,


-Ursprüngliche Nachricht-
Von: Strib 
Gesendet: Montag, 24. Oktober 2022 08:10
An: users@tomcat.apache.org
Betreff: Apache Tomcat started, but error 404

Hello, trying to see if anyone else had this issue. After a reboot of

hot and

warm servers, my sites using Tomcat throws the error 404 only on the hot
servers. I've stopped and started Tomcat services, nothing. In the logs,

there

were 2 errors. One was Catalina. But even though the error happened on

hot

and warm servers, warm sites are still working, so I'm thinking that's

not it. The

other error on the hot servers says startup error. Is it just luck of

the draw, of

starting/stopping Tomcat services?
Is it something else, entirely? Frustrating that Tomcat does not have a

UI to

make this easier. Thanks in advance.

Very respectfully,
Darious


Could you past the error message about startup issue?
404 sounds like your application failed to start but Tomcat is running.
So it might be an issue with the application.
In the log files there are usually information about the reason.

Greetings, Thomas





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

Re: Apache Tomcat started, but error 404

[Strib]

Hi Mark,

Due to the security echelon of the network, I can not send the entire
stacktrace.

However, I can say that it also states the web app archives are not
starting. (IllegalStateException: Error starting child).
Prominent "caused by" lines state bean creation errors, or instantiating
[org.grails.orm.hibernate.HibernateDatastore]: Constructor threw exception;
nested exception is
org.hibernate.tool.schema.extract.spi.SchemaExtractionException...

Very respectfully,
Darious


On Mon, Oct 24, 2022 at 4:31 PM Mark Thomas  wrote:

> On 24/10/2022 08:01, Strib wrote:
> > Hello and thank you,
> >
> > The error message reads as follows:
> > 'org.apache.catalina.LifecycleException: Failed to start component
> >
> [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/APPWARFILE]]'
>
> And the rest of that message? What does the stack trace show?
>
> There may also be earlier errors in the logs that are relevant.
>
> Mark
>
>
> > There are two app files trying to start, and both are getting the same
> > error. The weird part is, these app packages were not touched since
> before
> > the summer. Server patches have happened since, but this is the first
> month
> > where Tomcat is doing this So, two key notes:
> > 1: app packages have not been changed.
> > 2: hot and warm servers have been patched, but only hot servers received
> > this Tomcat error. This is the first month I've seen Tomcat not start
> > properly, which makes me believe it's Tomcat.
> > Also, just FYI, this is for Tomcat 8.
> >
> > Very respectfully,
> > Darious
> >
> >
> > On Mon, Oct 24, 2022 at 3:28 PM Thomas Hoffmann (Speed4Trade GmbH)
> >  wrote:
> >
> >> Hello,
> >>
> >>> -Ursprüngliche Nachricht-
> >>> Von: Strib 
> >>> Gesendet: Montag, 24. Oktober 2022 08:10
> >>> An: users@tomcat.apache.org
> >>> Betreff: Apache Tomcat started, but error 404
> >>>
> >>> Hello, trying to see if anyone else had this issue. After a reboot of
> >> hot and
> >>> warm servers, my sites using Tomcat throws the error 404 only on the
> hot
> >>> servers. I've stopped and started Tomcat services, nothing. In the
> logs,
> >> there
> >>> were 2 errors. One was Catalina. But even though the error happened on
> >> hot
> >>> and warm servers, warm sites are still working, so I'm thinking that's
> >> not it. The
> >>> other error on the hot servers says startup error. Is it just luck of
> >> the draw, of
> >>> starting/stopping Tomcat services?
> >>> Is it something else, entirely? Frustrating that Tomcat does not have a
> >> UI to
> >>> make this easier. Thanks in advance.
> >>>
> >>> Very respectfully,
> >>> Darious
> >>
> >> Could you past the error message about startup issue?
> >> 404 sounds like your application failed to start but Tomcat is running.
> >> So it might be an issue with the application.
> >> In the log files there are usually information about the reason.
> >>
> >> Greetings, Thomas
> >>
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Apache Tomcat started, but error 404

[Mark Thomas]

On 24/10/2022 08:01, Strib wrote:

Hello and thank you,

The error message reads as follows:
'org.apache.catalina.LifecycleException: Failed to start component
[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/APPWARFILE]]'


And the rest of that message? What does the stack trace show?

There may also be earlier errors in the logs that are relevant.

Mark



There are two app files trying to start, and both are getting the same
error. The weird part is, these app packages were not touched since before
the summer. Server patches have happened since, but this is the first month
where Tomcat is doing this So, two key notes:
1: app packages have not been changed.
2: hot and warm servers have been patched, but only hot servers received
this Tomcat error. This is the first month I've seen Tomcat not start
properly, which makes me believe it's Tomcat.
Also, just FYI, this is for Tomcat 8.

Very respectfully,
Darious


On Mon, Oct 24, 2022 at 3:28 PM Thomas Hoffmann (Speed4Trade GmbH)
 wrote:


Hello,


-Ursprüngliche Nachricht-
Von: Strib 
Gesendet: Montag, 24. Oktober 2022 08:10
An: users@tomcat.apache.org
Betreff: Apache Tomcat started, but error 404

Hello, trying to see if anyone else had this issue. After a reboot of

hot and

warm servers, my sites using Tomcat throws the error 404 only on the hot
servers. I've stopped and started Tomcat services, nothing. In the logs,

there

were 2 errors. One was Catalina. But even though the error happened on

hot

and warm servers, warm sites are still working, so I'm thinking that's

not it. The

other error on the hot servers says startup error. Is it just luck of

the draw, of

starting/stopping Tomcat services?
Is it something else, entirely? Frustrating that Tomcat does not have a

UI to

make this easier. Thanks in advance.

Very respectfully,
Darious


Could you past the error message about startup issue?
404 sounds like your application failed to start but Tomcat is running.
So it might be an issue with the application.
In the log files there are usually information about the reason.

Greetings, Thomas





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

Re: Apache Tomcat started, but error 404

[Strib]

Hello and thank you,

The error message reads as follows:
'org.apache.catalina.LifecycleException: Failed to start component
[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/APPWARFILE]]'
There are two app files trying to start, and both are getting the same
error. The weird part is, these app packages were not touched since before
the summer. Server patches have happened since, but this is the first month
where Tomcat is doing this So, two key notes:
1: app packages have not been changed.
2: hot and warm servers have been patched, but only hot servers received
this Tomcat error. This is the first month I've seen Tomcat not start
properly, which makes me believe it's Tomcat.
Also, just FYI, this is for Tomcat 8.

Very respectfully,
Darious


On Mon, Oct 24, 2022 at 3:28 PM Thomas Hoffmann (Speed4Trade GmbH)
 wrote:

> Hello,
>
> > -Ursprüngliche Nachricht-
> > Von: Strib 
> > Gesendet: Montag, 24. Oktober 2022 08:10
> > An: users@tomcat.apache.org
> > Betreff: Apache Tomcat started, but error 404
> >
> > Hello, trying to see if anyone else had this issue. After a reboot of
> hot and
> > warm servers, my sites using Tomcat throws the error 404 only on the hot
> > servers. I've stopped and started Tomcat services, nothing. In the logs,
> there
> > were 2 errors. One was Catalina. But even though the error happened on
> hot
> > and warm servers, warm sites are still working, so I'm thinking that's
> not it. The
> > other error on the hot servers says startup error. Is it just luck of
> the draw, of
> > starting/stopping Tomcat services?
> > Is it something else, entirely? Frustrating that Tomcat does not have a
> UI to
> > make this easier. Thanks in advance.
> >
> > Very respectfully,
> > Darious
>
> Could you past the error message about startup issue?
> 404 sounds like your application failed to start but Tomcat is running.
> So it might be an issue with the application.
> In the log files there are usually information about the reason.
>
> Greetings, Thomas
>

Re: Apache Tomcat started, but error 404

[Strib]

Hello and thank you,

The error message reads as follows:
'org.apache.catalina.LifecycleException: Failed to start component
[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/APPWARFILE]]'
There are two app files trying to start, and both are getting the same
error. The weird part is, these app packages were not touched since before
the summer. Server patches have happened since, but this is the first month
where Tomcat is doing this So, two key notes:
1: app packages have not been changed.
2: hot and warm servers have been patched, but only hot servers received
this Tomcat error. This is the first month I've seen Tomcat not start
properly, which makes me believe it's Tomcat.
Also, just FYI, this is for Tomcat 8.

Very respectfully,
Darious


On Mon, Oct 24, 2022 at 3:28 PM Thomas Hoffmann (Speed4Trade GmbH)
 wrote:

> Hello,
>
> > -Ursprüngliche Nachricht-
> > Von: Strib 
> > Gesendet: Montag, 24. Oktober 2022 08:10
> > An: users@tomcat.apache.org
> > Betreff: Apache Tomcat started, but error 404
> >
> > Hello, trying to see if anyone else had this issue. After a reboot of
> hot and
> > warm servers, my sites using Tomcat throws the error 404 only on the hot
> > servers. I've stopped and started Tomcat services, nothing. In the logs,
> there
> > were 2 errors. One was Catalina. But even though the error happened on
> hot
> > and warm servers, warm sites are still working, so I'm thinking that's
> not it. The
> > other error on the hot servers says startup error. Is it just luck of
> the draw, of
> > starting/stopping Tomcat services?
> > Is it something else, entirely? Frustrating that Tomcat does not have a
> UI to
> > make this easier. Thanks in advance.
> >
> > Very respectfully,
> > Darious
>
> Could you past the error message about startup issue?
> 404 sounds like your application failed to start but Tomcat is running.
> So it might be an issue with the application.
> In the log files there are usually information about the reason.
>
> Greetings, Thomas
>

AW: Apache Tomcat started, but error 404

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

> -Ursprüngliche Nachricht-
> Von: Strib 
> Gesendet: Montag, 24. Oktober 2022 08:10
> An: users@tomcat.apache.org
> Betreff: Apache Tomcat started, but error 404
> 
> Hello, trying to see if anyone else had this issue. After a reboot of hot and
> warm servers, my sites using Tomcat throws the error 404 only on the hot
> servers. I've stopped and started Tomcat services, nothing. In the logs, there
> were 2 errors. One was Catalina. But even though the error happened on hot
> and warm servers, warm sites are still working, so I'm thinking that's not 
> it. The
> other error on the hot servers says startup error. Is it just luck of the 
> draw, of
> starting/stopping Tomcat services?
> Is it something else, entirely? Frustrating that Tomcat does not have a UI to
> make this easier. Thanks in advance.
> 
> Very respectfully,
> Darious

Could you past the error message about startup issue?
404 sounds like your application failed to start but Tomcat is running.
So it might be an issue with the application.
In the log files there are usually information about the reason.

Greetings, Thomas

Apache Tomcat started, but error 404

[Strib]

Hello, trying to see if anyone else had this issue. After a reboot of hot
and warm servers, my sites using Tomcat throws the error 404 only on the
hot servers. I've stopped and started Tomcat services, nothing. In the
logs, there were 2 errors. One was Catalina. But even though the error
happened on hot and warm servers, warm sites are still working, so I'm
thinking that's not it. The other error on the hot servers says startup
error. Is it just luck of the draw, of starting/stopping Tomcat services?
Is it something else, entirely? Frustrating that Tomcat does not have a UI
to make this easier. Thanks in advance.

Very respectfully,
Darious

Re: Question about serving a 404

[Mark Thomas]

On 10/09/2021 16:44, James H. H. Lampert wrote:

Our Tomcat team has been struggling with this issue for a few days:

If a request comes in for https://foo.com/bar.html, which doesn't exist, 
then a 404 is returned, and we see a standard Tomcat 404 page.


But if a request comes in for https://foo.com/bar.jsp, which also 
doesn't exist, then our webapp takes control, and returns a 200 with a 
redirect to a "you are not signed on" page.


In the most recent attempt to correct this, they now return a 404 page 
of their own design for both of the above scenarios. Unfortunately, if 
the webapp context we're trying to reach is installed as something other 
than ROOT (i.e., if we call it "baz," then https://foo.com/baz), then 
even a correct URL still returns a 404 page.


Seems to me that there's something wrong with this picture. Seems to me 
that a request for a nonexistent "bar.jsp" should behave the same as one 
for a nonexistent "bar.html."


Is there something I can pass along to the Tomcat team?


Sounds like whatever is responding *.jsp requests is a little over 
eager. Depending on exactly what that is (Tomcat's JSP Servlet, custom 
Servlet, Filter) there are different things that might be able to help.


Mark

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

Question about serving a 404

[James H. H. Lampert]

Our Tomcat team has been struggling with this issue for a few days:

If a request comes in for https://foo.com/bar.html, which doesn't exist, 
then a 404 is returned, and we see a standard Tomcat 404 page.


But if a request comes in for https://foo.com/bar.jsp, which also 
doesn't exist, then our webapp takes control, and returns a 200 with a 
redirect to a "you are not signed on" page.


In the most recent attempt to correct this, they now return a 404 page 
of their own design for both of the above scenarios. Unfortunately, if 
the webapp context we're trying to reach is installed as something other 
than ROOT (i.e., if we call it "baz," then https://foo.com/baz), then 
even a correct URL still returns a 404 page.


Seems to me that there's something wrong with this picture. Seems to me 
that a request for a nonexistent "bar.jsp" should behave the same as one 
for a nonexistent "bar.html."


Is there something I can pass along to the Tomcat team?

--
JHHL

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

Re: GOAWAY sent on 404 with large payload in http2

[Doug Whitfield]

Regarding the email thread with this title: “Embedded Tomcat 9.0.43 : 
WINDOW_UPDATE not sent when receiving http2 requests over unknown url”

That looks exactly like our issue, but with slightly different numbers.

From: Doug Whitfield 
Date: Tuesday, March 9, 2021 at 4:02 PM
To: users@tomcat.apache.org 
Subject: GOAWAY sent on 404 with large payload in http2
Hi folks,

It is unclear if this is a Tomcat issue, a protocol issue, or something else. I 
would like some help figuring out if it is a Tomcat issue and then resolving 
the issue if it is. We have seen this issue in Tomcat 9.0.38 through 9.0.43.

For a handful of requests, Tomcat sends GOAWAY with below reason :
GOAWAY with FRAME_SIZE_ERROR : The payload is [2105376] bytes long but the 
maximum frame size is [16384]
The payload size here from the user point of view is around 55 KB, but we’ve 
tested similar payload sizes with similar results.



Steps to reproduce:
1. client sends an request of size 90KB to an unknown URL (means 
servlet-context was not deployed) towards tomcat.
2. Tomcat sends 404 page not found which is expected.
3. Tomcats sends RST_STREAM with CANCEL as reason.
4. Tomcat doesn't send WINDOW_UPDATE after this.
5. Client was not able to send further DATA frames towards Tomcat.
6. Client is able to send only HEADERS (to an deployed URL), but no DATA, all 
requests on that connection fails.
The above flow works properly when client sends an request to an correct 
deployed URL. The obvious response is to just use the correct URLs in 
applications, but we want to make sure this is not a security vulnerability.

All properties are the tomcat defaults.
Here are the connector details:
Connector connector = new Connector();
connector.setPort(1080);
Http2Protocol http2Protocol = new Http2Protocol();
connector.addUpgradeProtocol( http2Protocol );
tomcat.setConnector(connector);


Windows 10 (but also reproduced on Red Hat 7.4)
Processor: Intel(R) Core(TM) i5-8350U CPU @ 1.70GHz 1.90GHz
RAM:16 GB
System Type : 64 bit

How we reproduced:
With JMeter as simulation client, on configuring 700 threads (700 connections) 
to connect towards Tomcat Server 9.0.43 embedded in the application and on 
sending 20 requests per second with payload of 55KB (same request with just one 
json value sent uniquely via the Random number generator) and on running the 
test in an infinite loop , few requests are getting timed out . On analyzing 
the PCAP for the requests that timed-out we see that tomcat sends GOAWAY with  
PROTOCOL ERROR / FRAME_SIZE_ERROR .

Client:
JMeter 5.3 with additional HTTP2 sampler and Xmx 5g.
No of threads: 700
Ramp-up period: 10 seconds
Loop: Infinite
Payload size: around 55KB
Constant Throughput Timer added to limit the tps to 20.
Random Variable Generator added to the JSON request to uniquely identify for 
which request the exception is printed and to map it in the PCAP collected .
Response Timeout : 5000 ms

SERVER:
The input requests are processed asynchronously with 40 threads.




Are there any logs I should look at, and at what log level? There wasn’t 
anything obviously useful at FINER.

Please let me know if there is any additional information that would be useful.


Best Regards,
--

Doug Whitfield | Enterprise Architect, 
OpenLogic<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openlogic.com%2F%3Futm_leadsource%3Demail-signature%26utm_source%3Doutlook-direct-email%26utm_medium%3Demail%26utm_campaign%3D2019-common%26utm_content%3Demail-signature-linkdata=04%7C01%7Cdwhitfield%40perforce.com%7Cee15754dd3ae42fc792408d8e34709a1%7C95b666d19a7549ab95a38969fbcdc08c%7C0%7C0%7C637509241697963952%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=LAwM%2FysWiVMfHqiZ4OQ4bw7YB8gq4CZepoIz3mkqduQ%3Dreserved=0>
Perforce 
Software<http://www.perforce.com/?utm_leadsource=email-signature_source=outlook-direct-email_medium=email_campaign=2019-common_content=email-signature-link>
Visit us on: 
LinkedIn<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fcompany%2Fperforce%3Futm_leadsource%3Demail-signature%26utm_source%3Doutlook-direct-email%26utm_medium%3Demail%26utm_campaign%3D2019-common%26utm_content%3Demail-signature-linkdata=04%7C01%7Cdwhitfield%40perforce.com%7Cee15754dd3ae42fc792408d8e34709a1%7C95b666d19a7549ab95a38969fbcdc08c%7C0%7C0%7C637509241697973946%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=8%2Fw8RczUp8k4glOsUxCOB5wg8jejdb11wk1xCY%2FtRuA%3Dreserved=0>
 | 
Twitter<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fperforce%3Futm_leadsource%3Demail-signature%26utm_source%3Doutlook-direct-email%26utm_medium%3Demail%26utm_campaign%3D2019-common%26utm_content%3Demail-signature-linkdata=04%7C01%7Cdwhitfield%40perforce.com%7Cee15754dd3ae42fc792408d8e34709a1%7C95b666d19a7549ab95a38969fbcdc08c%7C0%7C0%7C6375092

GOAWAY sent on 404 with large payload in http2

[Doug Whitfield]

Hi folks,

It is unclear if this is a Tomcat issue, a protocol issue, or something else. I 
would like some help figuring out if it is a Tomcat issue and then resolving 
the issue if it is. We have seen this issue in Tomcat 9.0.38 through 9.0.43.

For a handful of requests, Tomcat sends GOAWAY with below reason :
GOAWAY with FRAME_SIZE_ERROR : The payload is [2105376] bytes long but the 
maximum frame size is [16384]
The payload size here from the user point of view is around 55 KB, but we’ve 
tested similar payload sizes with similar results.



Steps to reproduce:
1. client sends an request of size 90KB to an unknown URL (means 
servlet-context was not deployed) towards tomcat.
2. Tomcat sends 404 page not found which is expected.
3. Tomcats sends RST_STREAM with CANCEL as reason.
4. Tomcat doesn't send WINDOW_UPDATE after this.
5. Client was not able to send further DATA frames towards Tomcat.
6. Client is able to send only HEADERS (to an deployed URL), but no DATA, all 
requests on that connection fails.
The above flow works properly when client sends an request to an correct 
deployed URL. The obvious response is to just use the correct URLs in 
applications, but we want to make sure this is not a security vulnerability.

All properties are the tomcat defaults.
Here are the connector details:
Connector connector = new Connector();
connector.setPort(1080);
Http2Protocol http2Protocol = new Http2Protocol();
connector.addUpgradeProtocol( http2Protocol );
tomcat.setConnector(connector);


Windows 10 (but also reproduced on Red Hat 7.4)
Processor: Intel(R) Core(TM) i5-8350U CPU @ 1.70GHz 1.90GHz
RAM:16 GB
System Type : 64 bit

How we reproduced:
With JMeter as simulation client, on configuring 700 threads (700 connections) 
to connect towards Tomcat Server 9.0.43 embedded in the application and on 
sending 20 requests per second with payload of 55KB (same request with just one 
json value sent uniquely via the Random number generator) and on running the 
test in an infinite loop , few requests are getting timed out . On analyzing 
the PCAP for the requests that timed-out we see that tomcat sends GOAWAY with  
PROTOCOL ERROR / FRAME_SIZE_ERROR .

Client:
JMeter 5.3 with additional HTTP2 sampler and Xmx 5g.
No of threads: 700
Ramp-up period: 10 seconds
Loop: Infinite
Payload size: around 55KB
Constant Throughput Timer added to limit the tps to 20.
Random Variable Generator added to the JSON request to uniquely identify for 
which request the exception is printed and to map it in the PCAP collected .
Response Timeout : 5000 ms

SERVER:
The input requests are processed asynchronously with 40 threads.




Are there any logs I should look at, and at what log level? There wasn’t 
anything obviously useful at FINER.

Please let me know if there is any additional information that would be useful.


Best Regards,
--

Doug Whitfield | Enterprise Architect, 
OpenLogic<https://www.openlogic.com/?utm_leadsource=email-signature_source=outlook-direct-email_medium=email_campaign=2019-common_content=email-signature-link>
Perforce 
Software<http://www.perforce.com/?utm_leadsource=email-signature_source=outlook-direct-email_medium=email_campaign=2019-common_content=email-signature-link>
Visit us on: 
LinkedIn<https://www.linkedin.com/company/perforce?utm_leadsource=email-signature_source=outlook-direct-email_medium=email_campaign=2019-common_content=email-signature-link>
 | 
Twitter<https://twitter.com/perforce?utm_leadsource=email-signature_source=outlook-direct-email_medium=email_campaign=2019-common_content=email-signature-link>
 | 
Facebook<https://www.facebook.com/perforce/?utm_leadsource=email-signature_source=outlook-direct-email_medium=email_campaign=2019-common_content=email-signature-link>
 | 
YouTube<https://www.youtube.com/user/perforcesoftware?utm_leadsource=email-signature_source=outlook-direct-email_medium=email_campaign=2019-common_content=email-signature-link>




This e-mail may contain information that is privileged or confidential. If you 
are not the intended recipient, please delete the e-mail and any attachments 
and notify us immediately.

Re: javadoc 404

[Mark Thomas]

On 11/01/2021 04:51, Rob Sargent wrote:
> While trying to understand why PerUserPoolDataSource doesn't implement
> javax.sql.ConnectionPoolDataSource on
> 
>   
> https://tomcat.apache.org/tomcat-9.0-doc/api/org/apache/tomcat/dbcp/dbcp2/datasources/package-summary.html
> 
> 
> I get a 404 from anchor cpdsadapter example
> 
>   
> https://tomcat.apache.org/tomcat-9.0-doc/api/org/apache/tomcat/dbcp/dbcp2/cpdsadapter/package.html

I've fixed the link in the upstream Commons DBCP2 project. We'll pull in
an updated version of DBCP2 for the next release and the docs on the
website will reflect that change after the next release.

Mark

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

Re: javadoc 404

[Mark Eggers]

Rob,

On 1/10/2021 8:51 PM, Rob Sargent wrote:
While trying to understand why PerUserPoolDataSource doesn't implement 
javax.sql.ConnectionPoolDataSource on



https://tomcat.apache.org/tomcat-9.0-doc/api/org/apache/tomcat/dbcp/dbcp2/datasources/package-summary.html 



I get a 404 from anchor cpdsadapter example


https://tomcat.apache.org/tomcat-9.0-doc/api/org/apache/tomcat/dbcp/dbcp2/cpdsadapter/package.html 






I went to https://tomcat.apache.org/tomcat-9.0-doc/api/overview-summary.html

and then

https://tomcat.apache.org/tomcat-9.0-doc/api/org/apache/tomcat/dbcp/dbcp2/cpdsadapter/package-summary.html 



with no issue. Maybe an internal link is broken?

. . . just my two cents
/mde/



OpenPGP_signature
Description: OpenPGP digital signature

javadoc 404

[Rob Sargent]

While trying to understand why PerUserPoolDataSource doesn't implement 
javax.sql.ConnectionPoolDataSource on


   
https://tomcat.apache.org/tomcat-9.0-doc/api/org/apache/tomcat/dbcp/dbcp2/datasources/package-summary.html

I get a 404 from anchor cpdsadapter example

   
https://tomcat.apache.org/tomcat-9.0-doc/api/org/apache/tomcat/dbcp/dbcp2/cpdsadapter/package.html

Re: Rewritten requests returning 404 in 8.5.57

[Barry Roberts]

On Fri, Aug 7, 2020 at 7:52 AM Christopher Schultz
 wrote:
>
> Can you try 8.5.52 and see if that fails as well?---

/me hangs head in shame.

I haven't had time to narrow down what the exact issue is (I suspect
APR), but there's something in the new (8.5.57) Dockerfile that breaks
rewrites for me.  In trying to find an 8.5.52 release (never did) and
trying 8.5.53, I also ended up building and testing an 8.5.51 docker
from the 8.5.57 Dockerfile, and rewrites were broken in that image.

So, I've updated my old Dockerfile with 8.5.57 SHA512 and version, and
now the rewrites work just fine.  I'll probably try to narrow it down
and see if I need to submit a defect on github, but for now, gotta get
8.5.57 in the pipeline.

Thanks for all the help.

Barry

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

Re: Rewritten requests returning 404 in 8.5.57

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Barry,

On 8/6/20 16:20, Barry Roberts wrote:
> On Thu, Aug 6, 2020 at 1:23 PM Christopher Schultz
>  wrote:
>>
>> Are you trying to redirect across contexts (from one web
>> application to another)? If so, you need to make sure you are
>> actually doing a redirect. Your RewriteRules aren't redirecting.
>>
>> Try the [R] flag.
>>
>> - -chris
>
> Actually, no.  We used to have 3 similar but distinct apps deployed
> at /apps/iv /ivplugin and /apps/ivplugin. Now the code has
> converged, and there's only one app

Okay, that's probably not the problem, then.

> , but for a while we need to continue to use all the old paths.
Ack.

> The rewrite rules let me deploy one app instead of deploying the
> same app 3 times.  And it was working just fine in (at least)
> 8.5.51. We've been using this hack for nearly a year.

I'm not sure I'd call it a hack per se. It's a migration. :) (Our
marketing team has switched web site providers a few times and we have
a 5-page list of httpd "Redirect" directives for the same kind of thing.
)

Can you try 8.5.52 and see if that fails as well? I'm wondering if
this fix in 8.5.52 has changed something for you:

"
Fix: Modify the RewriteValve to use ServletRequest.getServerName() to
populate the HTTP_HOST variable rather than extracting it from the
Host header as this allows HTTP/2 to be supported. (markt)
"

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8tXGoACgkQHPApP6U8
pFhKlg/+OlrDhAKW/6KJpTiWdC3U+bOWFg3LzgvSNTs3+m+jB6jHd4ljVed22rSL
5VdM7ldfNxPG4lsZhn2U0MRgbAcaIEVOeipi9u2UgLmzGSX7n+TZz2EuFRBWmmri
w5Mg1Q7ZUDHVMmb8ymRO9z6M+jELQsFKDZOBrqjjBZVf9Od6RrJbs78VJcIF6jOW
dX83Ea1EqVhP15NW8kC4duObCCBP/sNdLR2Em/B4Z8PRoZGy7SefuDqLxD40GH5/
Wme8LVrqTJFTqXrxlI2yuqxGoO4s9BaJ2aAXH0RxXPpT2Cvz2C8AWYTEZNjsl3vX
kwx9tIiwQ6SDSRZpzyknTszVFPUv83dMAmlu28s5Usm1GEJ8cifH/FMAfeC4l7FH
03VhbjjjB5S8ZQI1KnFPcrO4684NZVv4boU0Yu/rmvBewzNrg3+dDgEXlxo5Kttl
+HF5Yi5q/KYDUedbB8ppRocfqHZIoSuTRsl0bRKHzEEIB/LSTr1Lvuq9+xVtp11X
PLF8Ds5spsDy1ufyprJhFGbNgdzAM5n5L2AreAgKIGd5arpwKjjPrGOM9z1+9wvc
HUL8w/fsFaKF7EKUFEckwIpCsLUzjPkEisuJhFszdmFp6ZQyAhU3WnJycrBmvOlI
S/KvZNbq9iXNAemyA8NuofKBaC7WoNlqffr/thevW317obI8WMM=
=r4RB
-END PGP SIGNATURE-

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

Re: Rewritten requests returning 404 in 8.5.57

[Barry Roberts]

On Thu, Aug 6, 2020 at 1:23 PM Christopher Schultz
 wrote:
>
> Are you trying to redirect across contexts (from one web application
> to another)? If so, you need to make sure you are actually doing a
> redirect. Your RewriteRules aren't redirecting.
>
> Try the [R] flag.
>
> - -chris

Actually, no.  We used to have 3 similar but distinct apps deployed at
/apps/iv /ivplugin and /apps/ivplugin. Now the code has converged, and
there's only one app, but for a while we need to continue to use all
the old paths.  The rewrite rules let me deploy one app instead of
deploying the same app 3 times.  And it was working just fine in (at
least) 8.5.51.  We've been using this hack for nearly a year.

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

Re: Rewritten requests returning 404 in 8.5.57

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Barry,

On 8/6/20 14:36, Barry Roberts wrote:
> On Thu, Aug 6, 2020 at 9:51 AM Mark Thomas 
> wrote:
>>
>>
>> Minimum steps to recreate the issue with an 8.5.57 install of a
>> standard ASF provided distribution?
>>
>> Mark
>>
>
> A minimal example similar to what I'm doing in 8.5.57, the
> redirects work as expected.
>
> I'm at a loss as to what configuration I have that causes a valid
> redirected path (I can copy it from the access log) will 404, but
> if I paste it into my browser, it works.  If anyone has any ideas,
> I'm all ears.
>
> I have:  className="org.apache.catalina.valves.rewrite.RewriteValve" />
>
> in the Host element in my server.xml, and
> conf/Catalina/localhost/rewrite.config contains: RewriteRule
> ^/ivplugin(.*)$ /apps/iv$1?XV_ORIG_PATH=%{REQUEST_URI} [QSA,L]
> RewriteRule ^/apps/ivplugin(.*)$
> /apps/iv$1?XV_ORIG_PATH=%{REQUEST_URI} [QSA,L]

Are you trying to redirect across contexts (from one web application
to another)? If so, you need to make sure you are actually doing a
redirect. Your RewriteRules aren't redirecting.

Try the [R] flag.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8sWIoACgkQHPApP6U8
pFj72Q/8DMBohsOQInDOreZVJDCVheOUyEkppWMNI39ZxpO5to5QQTD++06nprvs
+750zX815hcI6XhRqXua85LiUkCCUMyWa8J8SGBotoljG4gNPVqoKA4UI1x1bbgz
ztuoi9wPep5L59FFGRnnESl/l4lWGLWInmcw+2zoMXxorArFzUqOWsuSf+nSDYlJ
lz84AcGlbUZnexEDSRmO7V3+TuXC5lrvxUv62oUJpsDmhNkPvaaaA/cVEBZMQSnD
gxIOlxQeJk7klsYt6hH/2SRZWKeE4KZ8lW1EdkyCq9P+W6oozV2DhCS6F6oM7JDd
yIIoPytdvZkD3UwXgIwT//Af5W6WGbeFJlXGhUiVUx8gvQKRLDE+vtLmEaB1DG7B
kRelvSYkbhjzBtBA1+On8LX1+FxFrXIGMFDBrUqh9AxRSYGehP3uB5273PVrbqu7
Z6oPgqmTM/4c0mHsHKHVMEILcbJryLCvJaysxRg++hgqbicu+6EVtVjG7suvEXFI
i7/nCzBsGGgitLPlRB7OQSfkcB1XnrtNXG29qHZ0UOOVuqnGSNFm8jFQnyh8eZFA
mYmLVc621HbuSuC8vBOQMJDoMm1+dL7gEwrSRpkbcoyQDA68VQdZPsoCwybwGqST
0sir9GgZIGwEchXqXYXRG5fw9IbhGLFT9Y2t80tesneHNxGkM3o=
=q7rx
-END PGP SIGNATURE-

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

Re: Rewritten requests returning 404 in 8.5.57

[Barry Roberts]

On Thu, Aug 6, 2020 at 9:51 AM Mark Thomas  wrote:
>
>
> Minimum steps to recreate the issue with an 8.5.57 install of a standard ASF 
> provided distribution?
>
> Mark
>

A minimal example similar to what I'm doing in 8.5.57, the redirects
work as expected.

I'm at a loss as to what configuration I have that causes a valid
redirected path (I can copy it from the access log) will 404, but if I
paste it into my browser, it works.  If anyone has any ideas, I'm all
ears.

I have:
  

in the Host element in my server.xml, and
conf/Catalina/localhost/rewrite.config contains:
RewriteRule ^/ivplugin(.*)$ /apps/iv$1?XV_ORIG_PATH=%{REQUEST_URI} [QSA,L]
RewriteRule ^/apps/ivplugin(.*)$ /apps/iv$1?XV_ORIG_PATH=%{REQUEST_URI} [QSA,L]

Thanks,
Barry

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

Re: Rewritten requests returning 404 in 8.5.57

[Mark Thomas]

On August 6, 2020 2:37:34 PM UTC, Barry Roberts  wrote:
>I'm having an issue very similar to this one:
>https://marc.info/?l=tomcat-user=159171480518941=2
>
>The only difference is, I'm upgrading my docker from 8.5.51 to 8.5.57.
>My config adds a parameter in the rewrite rule, so I can see in the
>access log that the rule is rewriting properly.  It just returns a
>404.
>
>I'm using the Dockerfile from here:
>https://github.com/docker-library/tomcat/blob/master/8.5/jdk11/openjdk-slim-buster/Dockerfile
>
>Except, modified to use jdk 10.
>
>Everything has been working great in 8.5.51, and still does, but if I
>upgrade to 8.5.57, all rewritten requests return 404.
>
>I haven't tried 8.5.56.  Is this a known issue with 8.5.57?
>
>Thanks,
>Barry
>
>-
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org

Minimum steps to recreate the issue with an 8.5.57 install of a standard ASF 
provided distribution?

Mark

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

Rewritten requests returning 404 in 8.5.57

[Barry Roberts]

I'm having an issue very similar to this one:
https://marc.info/?l=tomcat-user=159171480518941=2

The only difference is, I'm upgrading my docker from 8.5.51 to 8.5.57.
My config adds a parameter in the rewrite rule, so I can see in the
access log that the rule is rewriting properly.  It just returns a
404.

I'm using the Dockerfile from here:
https://github.com/docker-library/tomcat/blob/master/8.5/jdk11/openjdk-slim-buster/Dockerfile

Except, modified to use jdk 10.

Everything has been working great in 8.5.51, and still does, but if I
upgrade to 8.5.57, all rewritten requests return 404.

I haven't tried 8.5.56.  Is this a known issue with 8.5.57?

Thanks,
Barry

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

Re: Getting 404 error while accessing URL after deployment

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Megha,

On 5/5/20 00:23, Megha Agrawal wrote:
> Hi,
>
>> Where did you look for the logs ?
> I look into the files inside the logs folder.
>
>> Please check your Tomcat configuration. If there are errors
>> during the deployment they must be written to logs/catalina.out.
>
> There is no file named Catalina.out in the logs folder. In
> logs/catalina.txt file no such error logged that means deployment
> of project is successful.> Project is deploying successfully but
> unable to run the API related to project.

Usually on Windows, using the Windows Service, you'll see some other
files and not catalina.out. I think they are something like
localhost-stdout-[date].txt or something like that.

But you should stop Tomcat, delete all logs, start Tomcat and inspect
every file in the logs/ directory to see if there are any indications
of what may be the problem.

- -chris

> From: Martin Grigorov Sent: Monday, May 4, 2020 7:49 PM To: Tomcat
> Users List Subject: Re: Getting 404 error while accessing URL after
> deployment
>
> Hi,
>
> On Mon, May 4, 2020 at 5:02 PM Megha Agrawal 
> wrote:
>
>> Hi
>>
>> I am trying to deploy my project on the tomcat server and access
>> the URL using browser. Project is deploying successfully on the
>> server but unable to access URL related to that project. Also,
>> logs are not generating for the deployment and request. Therefore
>> unable to find the reason for the problem.
>>
>
> Where did you look for the logs ? Please check your Tomcat
> configuration. If there are errors during the deployment they must
> be written to logs/catalina.out.
>
>
>>
>> I am using the following configurations: Tomcat version: 9.0.34
>> Operating system: Windows 10 (64-bit) IDE: Eclipse (Version:
>> 2019-03 (4.11.0), Build id: 20190314-1200) Java: JDK-8
>>
>> The same project is running fine on other machines and also other
>> projects are running fine on this server. Please look into this
>> issue and provide some details about it.
>>
>> Thanks and regards Megha Agrawal
>>
>
>
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6yyRUACgkQHPApP6U8
pFiVoQ//Uy1HmvCPat7XG1yURUzTpzU9yyB9De94+wnMy3jWSK9wcNRNF/4R2QC5
9ehATbhLIWm1fBi+JZV4Ihxl61G9fcj88JdiET1NrZ9i4xK3MBV57yCTEKCVTjp+
ED6m65JuCsx6p0h0ymWqHjI8sKrDNa2oKEIUj2jhn4H3yVBKTfxS3lsc3+UjHL/S
hd/MYgRFd8xaxsrBJx88uklzdwWkDBNlbxW+UP30gR9ssmkBDrQ1oCHLBgvhH5K5
if4kFtSMTDG4bnN3Tb01btIwOYyRbLfovLzy4T3GRxeHa1RxBiyoDZVaKGuOxZsu
m6AMHL98fPieHqlUfuUIkFS7SHh6LBWQDCu49JEUNxGCMw1D7VJrCsQ4jJ0fVPsB
RCnDNOCXcxInFDSvLe1hhyav4VMLil3492IGHAWzgBhlNBhm8Hq7lc8ZZER7t0hQ
Y3izZLoLauHoGX1aMb3Yr/ul2hAgbMHbd0EX/US38mJZtGDnBfxuNtPZMHJIeXgW
D+kmCO9b9H0i7M6IeNJ569dx4Cb+slfae2PcP8RkRKkgVr2oFciQOkXd9ztzt0yc
HWhGe0dHNLKBHGuZkvCsQQb+qHcUEEqzALujOMrUzxIVd2ML07Xqfe6XB6d8TS50
S8e+MctoejJZXWegezNiS3EdoFMXyuOmiBp2fYN4kyCUi0ssefg=
=HTXS
-END PGP SIGNATURE-

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

Re: Getting 404 error while accessing URL after deployment

[Luis Rodríguez Fernández]

Hello Megha,

I am afraid that with that information you can not be sure if your webapp
has been deployed or not. Maybe you can have a look at the manager app of
your tomcat [1] instance (http://localhost:8080/manager), or query for the
state of the applications using the jmxproxyservlet (
http://localhost:8080/manager/jmxproxy/?qry=*:j2eeType=WebModule,*)

About the logs: I would recommend you to increase the level. The tomcat
logging [2] can be a good place to start, or check in your application
sources, chances are that you are using some logging framework.

Hope it helps,

Luis

[1] http://tomcat.apache.org/tomcat-9.0-doc/manager-howto.html
[2] http://tomcat.apache.org/tomcat-9.0-doc/logging.html

El mar., 5 may. 2020 a las 6:23, Megha Agrawal ()
escribió:

> Hi,
>
> > Where did you look for the logs ?
> I look into the files inside the logs folder.
>
> >Please check your Tomcat configuration. If there are errors during the
> >deployment they must be written to logs/catalina.out.
>
> There is no file named Catalina.out in the logs folder. In
> logs/catalina.txt file no such error logged that means deployment of
> project is successful.
> Project is deploying successfully but unable to run the API related to
> project.
>
> Thanks
> Megha Agrawal
>
>
> From: Martin Grigorov
> Sent: Monday, May 4, 2020 7:49 PM
> To: Tomcat Users List
> Subject: Re: Getting 404 error while accessing URL after deployment
>
> Hi,
>
> On Mon, May 4, 2020 at 5:02 PM Megha Agrawal  wrote:
>
> > Hi
> >
> > I am trying to deploy my project on the tomcat server and access the URL
> > using browser. Project is deploying successfully on the server but unable
> > to access URL related to that project. Also, logs are not generating for
> > the deployment and request. Therefore unable to find the reason for the
> > problem.
> >
>
> Where did you look for the logs ?
> Please check your Tomcat configuration. If there are errors during the
> deployment they must be written to logs/catalina.out.
>
>
> >
> > I am using the following configurations:
> > Tomcat version: 9.0.34
> > Operating system: Windows 10 (64-bit)
> > IDE: Eclipse (Version: 2019-03 (4.11.0), Build id: 20190314-1200)
> > Java: JDK-8
> >
> > The same project is running fine on other machines and also other
> projects
> > are running fine on this server.
> > Please look into this issue and provide some details about it.
> >
> > Thanks and regards
> > Megha Agrawal
> >
>
>

-- 

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

- Samuel Beckett

RE: Getting 404 error while accessing URL after deployment

[Megha Agrawal]

Hi,

> Where did you look for the logs ?
I look into the files inside the logs folder.

>Please check your Tomcat configuration. If there are errors during the
>deployment they must be written to logs/catalina.out.

There is no file named Catalina.out in the logs folder. In logs/catalina.txt 
file no such error logged that means deployment of project is successful.
Project is deploying successfully but unable to run the API related to project.

Thanks
Megha Agrawal


From: Martin Grigorov
Sent: Monday, May 4, 2020 7:49 PM
To: Tomcat Users List
Subject: Re: Getting 404 error while accessing URL after deployment

Hi,

On Mon, May 4, 2020 at 5:02 PM Megha Agrawal  wrote:

> Hi
>
> I am trying to deploy my project on the tomcat server and access the URL
> using browser. Project is deploying successfully on the server but unable
> to access URL related to that project. Also, logs are not generating for
> the deployment and request. Therefore unable to find the reason for the
> problem.
>

Where did you look for the logs ?
Please check your Tomcat configuration. If there are errors during the
deployment they must be written to logs/catalina.out.


>
> I am using the following configurations:
> Tomcat version: 9.0.34
> Operating system: Windows 10 (64-bit)
> IDE: Eclipse (Version: 2019-03 (4.11.0), Build id: 20190314-1200)
> Java: JDK-8
>
> The same project is running fine on other machines and also other projects
> are running fine on this server.
> Please look into this issue and provide some details about it.
>
> Thanks and regards
> Megha Agrawal
>

RE: Getting 404 error while accessing URL after deployment

[jonmcalexander]

Dream * Excel * Explore * Inspire
Jon McAlexander
Asst Vice President

Middleware Product Engineering
Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com


This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.


-Original Message-
From: Martin Grigorov  
Sent: Monday, May 4, 2020 9:19 AM
To: Tomcat Users List 
Subject: Re: Getting 404 error while accessing URL after deployment

Hi,

On Mon, May 4, 2020 at 5:02 PM Megha Agrawal  wrote:

> Hi
>
> I am trying to deploy my project on the tomcat server and access the 
> URL using browser. Project is deploying successfully on the server but 
> unable to access URL related to that project. Also, logs are not 
> generating for the deployment and request. Therefore unable to find 
> the reason for the problem.
>

Where did you look for the logs ?
Please check your Tomcat configuration. If there are errors during the 
deployment they must be written to logs/catalina.out.


>
> I am using the following configurations:
> Tomcat version: 9.0.34
> Operating system: Windows 10 (64-bit)
> IDE: Eclipse (Version: 2019-03 (4.11.0), Build id: 20190314-1200)
> Java: JDK-8
>
> The same project is running fine on other machines and also other 
> projects are running fine on this server.
> Please look into this issue and provide some details about it.
>
> Thanks and regards
> Megha Agrawal
>

Is your Tomcat implementation behind a web server and are you using AJP? If so, 
you may need to modify your AJP connector.

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

Re: Getting 404 error while accessing URL after deployment

[Martin Grigorov]

Hi,

On Mon, May 4, 2020 at 5:02 PM Megha Agrawal  wrote:

> Hi
>
> I am trying to deploy my project on the tomcat server and access the URL
> using browser. Project is deploying successfully on the server but unable
> to access URL related to that project. Also, logs are not generating for
> the deployment and request. Therefore unable to find the reason for the
> problem.
>

Where did you look for the logs ?
Please check your Tomcat configuration. If there are errors during the
deployment they must be written to logs/catalina.out.


>
> I am using the following configurations:
> Tomcat version: 9.0.34
> Operating system: Windows 10 (64-bit)
> IDE: Eclipse (Version: 2019-03 (4.11.0), Build id: 20190314-1200)
> Java: JDK-8
>
> The same project is running fine on other machines and also other projects
> are running fine on this server.
> Please look into this issue and provide some details about it.
>
> Thanks and regards
> Megha Agrawal
>

Getting 404 error while accessing URL after deployment

[Megha Agrawal]

Hi

I am trying to deploy my project on the tomcat server and access the URL using 
browser. Project is deploying successfully on the server but unable to access 
URL related to that project. Also, logs are not generating for the deployment 
and request. Therefore unable to find the reason for the problem.

I am using the following configurations:
Tomcat version: 9.0.34
Operating system: Windows 10 (64-bit)
IDE: Eclipse (Version: 2019-03 (4.11.0), Build id: 20190314-1200)
Java: JDK-8

The same project is running fine on other machines and also other projects are 
running fine on this server. 
Please look into this issue and provide some details about it. 

Thanks and regards
Megha Agrawal

Re: 404 response to URLs with trailing decimal

[Mark Thomas]

On April 19, 2019 5:32:11 PM UTC, Mark Reyes  wrote:
>Hello,
>
>I find that Tomcat 8 will not serve up static content with a trailing
>decimal in
>the URL.  A response code of 404 is served up, not the static content.
>
>My configuration is a symbolic link in the webapps/ directory. e.g.
>
> 
>
>   allowLinking="true"
>
> 
>
>A sample request URL that fails is:
> http://localhost:8080/externalData/trailingDot.
>
>I have tried to URL encode the period in the request, but the problem
>still
>exists.
>Is this a bug in Tomcat?  If so, should I send in a bug request?
>Below are the instance specifics.
>
>Thank you.
>mark.re...@ucop.edu
>
>Server version: Apache Tomcat/8.0.24
>Server built:   Jul 1 2015 20:19:55 UTC
>Server number:  8.0.24.0
>OS Name:Linux
>OS Version: 4.14.104-78.84.amzn1.x86_64
>Architecture:   amd64
>JVM Version:1.8.0_201-b09
>JVM Vendor: Oracle Corporation
>
>-
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org

Assuming the file /externalData/trailingDot. exists then yes, that looks like a 
bug.

Mark

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

404 response to URLs with trailing decimal

[Mark Reyes]

Hello,

I find that Tomcat 8 will not serve up static content with a trailing decimal in
the URL.  A response code of 404 is served up, not the static content.

My configuration is a symbolic link in the webapps/ directory. e.g.

 

   allowLinking="true"

 

A sample request URL that fails is:
 http://localhost:8080/externalData/trailingDot.

I have tried to URL encode the period in the request, but the problem still
exists.
Is this a bug in Tomcat?  If so, should I send in a bug request?
Below are the instance specifics.

Thank you.
mark.re...@ucop.edu

Server version: Apache Tomcat/8.0.24
Server built:   Jul 1 2015 20:19:55 UTC
Server number:  8.0.24.0
OS Name:Linux
OS Version: 4.14.104-78.84.amzn1.x86_64
Architecture:   amd64
JVM Version:1.8.0_201-b09
JVM Vendor: Oracle Corporation

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

Re: Tomcat gives 404 for file that exists

[Joel Griffith]

On Tue, Feb 5, 2019 at 9:49 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Joel,
>
> On 2/5/19 08:56, Joel Griffith wrote:
> > On Mon, Feb 4, 2019 at 4:50 PM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > Joel,
> >
> > On 2/4/19 16:35, Joel Griffith wrote:
> >>>> I've installed Tomcat 8.0.32 a local Ubuntu 16.04 VM (Oracle
> >>>> VirtualBox) and I'm using it to access a webapp through the
> >>>> laptop the VM is local to. The VM port-forwards 3081 to 8080,
> >>>> so I can access Tomcat as ` http://127.0.0.1:3081/`
> <http://127.0.0.1:3081/>
> >>>> <http://127.0.0.1:3081/> in
> > my laptop browser.
> >
> > Are you sure it's going to the Tomcat you think it's going to?
> >
> > I'm not at all certain.  I didn't even know there was more than
> > one.  How can I tell?
>
> I was thinking that maybe you had either more than one Tomcat running
> or that your port-forwarding wasn't working the way you thought it was.
>
> >> Accessing `http://127.0.0.1:3081/` <http://127.0.0.1:3081/> <
> http://127.0.0.1:3081/> gives
> >> the default page stored in
> >> `/var/lib/tomcat8/webapps/ROOT/index.html`.  So, Tomcat is able
> >> to find and serve from the `webapps/` directory.
> >>
> >> However, if I try to access
> >> `http://127.0.0.1:3081/myWebapp/index.html`
> <http://127.0.0.1:3081/myWebapp/index.html>, which exists as
> >> `/var/lib/tomcat8/webapps/myWebapp/index.html`, Tomcat returns a
> >> 404, reporting that the requested resource in unavailable.
> >>
> >> `/var/lib/tomcat8/webapps/myWebapp/WEB-INF/web.xml` exists and
> >> is identical to that used in a functioning setup on a different
> >> server.
> >>
> >> What am I missing?  Why can Tomcat find
> >> `webapps/ROOT/index.html` but not `webapps/myWebapp/index.html`?
> >
> > Do you have an AccessLogVave enabled for the server? Is it showing
> > your requests and the 404 response when you make a request?
> >
> >
> >> Yes, and yes.
>
> Okay, that's (sort of) good. It means that your request is going to
> the right place.
>
> If you delete your log files and start Tomcat cleanly, what does
> catalina.out say about which applications were started? You should
> have some log entries that look like this:
>
> INFO: Deploying web application directory [/path/to/your/webappp]
> ...
> INFO: Deployment of web application directory [/path/to/your/webapp]
> has finished in [6,417] ms
>
> That's the ticket.  The webapp wasn't deploying because I was missing a
class required by the webapp's web.xml.  I'll get that fixed.  Thanks for
your help!

>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxZon8ACgkQHPApP6U8
> pFho+Q//XYLSHMBzQKSWR4luiMXRaml5ahpWUqcgUa8h/753Aeeiks2Dgr0KcXgB
> dwCWxN/9VE1s+MHzKPWcvoaX2pWHW3ceABw8EzpftMQqrl6pMT9cfqY29d8B0Sbz
> mKyaIrV1qJrnG5bb+G89a8DhCyTroRF5BOXvkKQCiHIJhQ4Q6lihRa/HEYWFLA4l
> cKdfaTjSTfBtkJLfDaQ8+BlDRSY+lfk6joi0P3BOqkNn+kEgM6uTDBadN2NwsBP8
> C7rOK8+Fk2t938it9yPdi3lJ67NUCFbjb8HCYyt36UPuurPZV0ZVf4UdOqYmdPWF
> U+0fqh8XFIH+HLnLS85c+y0BSZ+MukjdkVqRGgiVGhF53icTtv6K1SVOUdI5jw8x
> LdOdn3s7QFCTV2Of3er3Vw/s4NcZRchKZhttd1KnEjAH3Op+IHo88YAGk+3R6bAg
> kCCDHXHs378o7SqVRqW10cujkUN4dAWfkt3/agS+VoRH92VtXFy/zOS++UlD+eBm
> 4tglZSwwhqkEs2tYA+ZDXe1A9e+op4dZ7y48yGo91dDo4E0uRnqrVWDNoROE7a4i
> nyCT4C8NrtP1UUyt43fYcUtbiWlYf1pQcUsVuYOSDkGWNA3Ejj7F8hDaj0XuwB9E
> XLxpjgbZSuf5+ifC+lJat8tBqKBDw+vDBJyKYAs1XqLMIm7WgFw=
> =fay0
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Tomcat gives 404 for file that exists

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Joel,

On 2/5/19 08:56, Joel Griffith wrote:
> On Mon, Feb 4, 2019 at 4:50 PM Christopher Schultz < 
> ch...@christopherschultz.net> wrote:
> 
> Joel,
> 
> On 2/4/19 16:35, Joel Griffith wrote:
>>>> I've installed Tomcat 8.0.32 a local Ubuntu 16.04 VM (Oracle 
>>>> VirtualBox) and I'm using it to access a webapp through the
>>>> laptop the VM is local to. The VM port-forwards 3081 to 8080,
>>>> so I can access Tomcat as ` http://127.0.0.1:3081/`
>>>> <http://127.0.0.1:3081/> in
> my laptop browser.
> 
> Are you sure it's going to the Tomcat you think it's going to?
> 
> I'm not at all certain.  I didn't even know there was more than
> one.  How can I tell?

I was thinking that maybe you had either more than one Tomcat running
or that your port-forwarding wasn't working the way you thought it was.

>> Accessing `http://127.0.0.1:3081/` <http://127.0.0.1:3081/> gives
>> the default page stored in
>> `/var/lib/tomcat8/webapps/ROOT/index.html`.  So, Tomcat is able 
>> to find and serve from the `webapps/` directory.
>> 
>> However, if I try to access 
>> `http://127.0.0.1:3081/myWebapp/index.html`, which exists as 
>> `/var/lib/tomcat8/webapps/myWebapp/index.html`, Tomcat returns a 
>> 404, reporting that the requested resource in unavailable.
>> 
>> `/var/lib/tomcat8/webapps/myWebapp/WEB-INF/web.xml` exists and
>> is identical to that used in a functioning setup on a different 
>> server.
>> 
>> What am I missing?  Why can Tomcat find
>> `webapps/ROOT/index.html` but not `webapps/myWebapp/index.html`?
> 
> Do you have an AccessLogVave enabled for the server? Is it showing 
> your requests and the 404 response when you make a request?
> 
> 
>> Yes, and yes.

Okay, that's (sort of) good. It means that your request is going to
the right place.

If you delete your log files and start Tomcat cleanly, what does
catalina.out say about which applications were started? You should
have some log entries that look like this:

INFO: Deploying web application directory [/path/to/your/webappp]
...
INFO: Deployment of web application directory [/path/to/your/webapp]
has finished in [6,417] ms


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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxZon8ACgkQHPApP6U8
pFho+Q//XYLSHMBzQKSWR4luiMXRaml5ahpWUqcgUa8h/753Aeeiks2Dgr0KcXgB
dwCWxN/9VE1s+MHzKPWcvoaX2pWHW3ceABw8EzpftMQqrl6pMT9cfqY29d8B0Sbz
mKyaIrV1qJrnG5bb+G89a8DhCyTroRF5BOXvkKQCiHIJhQ4Q6lihRa/HEYWFLA4l
cKdfaTjSTfBtkJLfDaQ8+BlDRSY+lfk6joi0P3BOqkNn+kEgM6uTDBadN2NwsBP8
C7rOK8+Fk2t938it9yPdi3lJ67NUCFbjb8HCYyt36UPuurPZV0ZVf4UdOqYmdPWF
U+0fqh8XFIH+HLnLS85c+y0BSZ+MukjdkVqRGgiVGhF53icTtv6K1SVOUdI5jw8x
LdOdn3s7QFCTV2Of3er3Vw/s4NcZRchKZhttd1KnEjAH3Op+IHo88YAGk+3R6bAg
kCCDHXHs378o7SqVRqW10cujkUN4dAWfkt3/agS+VoRH92VtXFy/zOS++UlD+eBm
4tglZSwwhqkEs2tYA+ZDXe1A9e+op4dZ7y48yGo91dDo4E0uRnqrVWDNoROE7a4i
nyCT4C8NrtP1UUyt43fYcUtbiWlYf1pQcUsVuYOSDkGWNA3Ejj7F8hDaj0XuwB9E
XLxpjgbZSuf5+ifC+lJat8tBqKBDw+vDBJyKYAs1XqLMIm7WgFw=
=fay0
-END PGP SIGNATURE-

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

Re: Tomcat gives 404 for file that exists

[Joel Griffith]

On Mon, Feb 4, 2019 at 4:50 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Joel,
>
> On 2/4/19 16:35, Joel Griffith wrote:
> > I've installed Tomcat 8.0.32 a local Ubuntu 16.04 VM (Oracle
> > VirtualBox) and I'm using it to access a webapp through the laptop
> > the VM is local to. The VM port-forwards 3081 to 8080, so I can
> > access Tomcat as ` http://127.0.0.1:3081/` <http://127.0.0.1:3081/> in
> my laptop browser.
>
> Are you sure it's going to the Tomcat you think it's going to?
>
> I'm not at all certain.  I didn't even know there was more than one.  How
can I tell?

> Accessing `http://127.0.0.1:3081/` <http://127.0.0.1:3081/> gives the
> default page stored
> > in `/var/lib/tomcat8/webapps/ROOT/index.html`.  So, Tomcat is able
> > to find and serve from the `webapps/` directory.
> >
> > However, if I try to access
> > `http://127.0.0.1:3081/myWebapp/index.html`
> <http://127.0.0.1:3081/myWebapp/index.html>, which exists as
> > `/var/lib/tomcat8/webapps/myWebapp/index.html`, Tomcat returns a
> > 404, reporting that the requested resource in unavailable.
> >
> > `/var/lib/tomcat8/webapps/myWebapp/WEB-INF/web.xml` exists and is
> > identical to that used in a functioning setup on a different
> > server.  It was originally written for a Tomcat 7 deployment, I
> > think, but there's nothing in it that seems to have anything to do
> > with these URLs, so I don't think it's a problem with that file.
> > Similarly, `/var/lib/tomcat8/conf/server.xml` exists and is
> > virtually identical to that used in the other (functioning)
> > deployment.
> >
> > All of the information I've been able to scrape together from web
> > searches over the past two days indicate that the presence of a
> > folder within the `webapps/` directory is sufficient for Tomcat to
> > recognize and register it as a Context.  I'm at a complete loss for
> > what else I need to do to have Tomcat serve the file
> > `webapps/myWebapp/index.html`
> >
> > What am I missing?  Why can Tomcat find `webapps/ROOT/index.html`
> > but not `webapps/myWebapp/index.html`?
>
> Do you have an AccessLogVave enabled for the server? Is it showing
> your requests and the 404 response when you make a request?
>

Yes, and yes.


> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxYs5gACgkQHPApP6U8
> pFgDGQ//VQnrKG77d+ciLUx5hgapoTR73DEHIIXD1vrbkPR9XLydjRcgnbTXFWzf
> xIH2rB2hROWAsA0T/GjaG87EfqFehlGmqa5isFNLqoah6Ss3wCvjvquwtdS+1OPX
> 0wxl2uqxgDmFVpMAOgmYGmp3HLi87nP/8h5Rn/Ef/Iqg3Z4CTKjvcUUhKRf3Lupw
> CYoPe3AFUOXTG40EKBDqzJ8IW2+Mt0rNfkU3T5v4BUtrKKc3ARof5CygVvgVS+5Q
> qpjH/p+hskvXWWuAz9is6+qAgu7WPyoV7KhOq93M9yQQ/bR7fNMfjVYg9q6z+UKO
> m6bNf+eQCtXfaHnDJp5Bytied0nUlCfBbHP6tvvNNl9B2jdaV4nT+9ZQIykOXN4E
> p64PvpHk8V2v/6GIlJ04E1LNiMwNycu3l24DnSn27sVxD6JKIMoTlyf4dvPK+zsw
> Jp8Bguiqog6geBpo+CNU1vzToWpiGHP/8rSwh9pbX7xpyTfWgq3bnvJmzNaVYJQ5
> ggPCRiMRFgPurIr5edvvlyaGp8gfeFtb1FgCTKNTg2J9j8yxVI2p30lT8L+I+Rxp
> Tpapvum6q1/NAtKigCuq7ylXpN3XQnOmJq7fb1a7+lYwzA0NQ3IC8uooSys4GNBb
> ijeTnYsCTJqXNZ9k5BiCkUgMEr5yo4qiAtmppTbelGoNsWno+Jc=
> =VZa6
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Tomcat gives 404 for file that exists

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Joel,

On 2/4/19 16:35, Joel Griffith wrote:
> I've installed Tomcat 8.0.32 a local Ubuntu 16.04 VM (Oracle
> VirtualBox) and I'm using it to access a webapp through the laptop
> the VM is local to. The VM port-forwards 3081 to 8080, so I can
> access Tomcat as ` http://127.0.0.1:3081/` in my laptop browser.

Are you sure it's going to the Tomcat you think it's going to?

> Accessing `http://127.0.0.1:3081/` gives the default page stored
> in `/var/lib/tomcat8/webapps/ROOT/index.html`.  So, Tomcat is able
> to find and serve from the `webapps/` directory.
> 
> However, if I try to access
> `http://127.0.0.1:3081/myWebapp/index.html`, which exists as
> `/var/lib/tomcat8/webapps/myWebapp/index.html`, Tomcat returns a
> 404, reporting that the requested resource in unavailable.
> 
> `/var/lib/tomcat8/webapps/myWebapp/WEB-INF/web.xml` exists and is
> identical to that used in a functioning setup on a different
> server.  It was originally written for a Tomcat 7 deployment, I
> think, but there's nothing in it that seems to have anything to do
> with these URLs, so I don't think it's a problem with that file.
> Similarly, `/var/lib/tomcat8/conf/server.xml` exists and is
> virtually identical to that used in the other (functioning)
> deployment.
> 
> All of the information I've been able to scrape together from web
> searches over the past two days indicate that the presence of a
> folder within the `webapps/` directory is sufficient for Tomcat to
> recognize and register it as a Context.  I'm at a complete loss for
> what else I need to do to have Tomcat serve the file
> `webapps/myWebapp/index.html`
> 
> What am I missing?  Why can Tomcat find `webapps/ROOT/index.html`
> but not `webapps/myWebapp/index.html`?

Do you have an AccessLogVave enabled for the server? Is it showing
your requests and the 404 response when you make a request?

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxYs5gACgkQHPApP6U8
pFgDGQ//VQnrKG77d+ciLUx5hgapoTR73DEHIIXD1vrbkPR9XLydjRcgnbTXFWzf
xIH2rB2hROWAsA0T/GjaG87EfqFehlGmqa5isFNLqoah6Ss3wCvjvquwtdS+1OPX
0wxl2uqxgDmFVpMAOgmYGmp3HLi87nP/8h5Rn/Ef/Iqg3Z4CTKjvcUUhKRf3Lupw
CYoPe3AFUOXTG40EKBDqzJ8IW2+Mt0rNfkU3T5v4BUtrKKc3ARof5CygVvgVS+5Q
qpjH/p+hskvXWWuAz9is6+qAgu7WPyoV7KhOq93M9yQQ/bR7fNMfjVYg9q6z+UKO
m6bNf+eQCtXfaHnDJp5Bytied0nUlCfBbHP6tvvNNl9B2jdaV4nT+9ZQIykOXN4E
p64PvpHk8V2v/6GIlJ04E1LNiMwNycu3l24DnSn27sVxD6JKIMoTlyf4dvPK+zsw
Jp8Bguiqog6geBpo+CNU1vzToWpiGHP/8rSwh9pbX7xpyTfWgq3bnvJmzNaVYJQ5
ggPCRiMRFgPurIr5edvvlyaGp8gfeFtb1FgCTKNTg2J9j8yxVI2p30lT8L+I+Rxp
Tpapvum6q1/NAtKigCuq7ylXpN3XQnOmJq7fb1a7+lYwzA0NQ3IC8uooSys4GNBb
ijeTnYsCTJqXNZ9k5BiCkUgMEr5yo4qiAtmppTbelGoNsWno+Jc=
=VZa6
-END PGP SIGNATURE-

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

Tomcat gives 404 for file that exists

[Joel Griffith]

I've installed Tomcat 8.0.32 a local Ubuntu 16.04 VM (Oracle VirtualBox)
and I'm using it to access a webapp through the laptop the VM is local to.
The VM port-forwards 3081 to 8080, so I can access Tomcat as `
http://127.0.0.1:3081/` in my laptop browser.

Accessing `http://127.0.0.1:3081/` gives the default page stored in
`/var/lib/tomcat8/webapps/ROOT/index.html`.  So, Tomcat is able to find and
serve from the `webapps/` directory.

However, if I try to access `http://127.0.0.1:3081/myWebapp/index.html`,
which exists as `/var/lib/tomcat8/webapps/myWebapp/index.html`, Tomcat
returns a 404, reporting that the requested resource in unavailable.

`/var/lib/tomcat8/webapps/myWebapp/WEB-INF/web.xml` exists and is identical
to that used in a functioning setup on a different server.  It was
originally written for a Tomcat 7 deployment, I think, but there's nothing
in it that seems to have anything to do with these URLs, so I don't think
it's a problem with that file.  Similarly,
`/var/lib/tomcat8/conf/server.xml` exists and is virtually identical to
that used in the other (functioning) deployment.

All of the information I've been able to scrape together from web searches
over the past two days indicate that the presence of a folder within the
`webapps/` directory is sufficient for Tomcat to recognize and register it
as a Context.  I'm at a complete loss for what else I need to do to have
Tomcat serve the file `webapps/myWebapp/index.html`

What am I missing?  Why can Tomcat find `webapps/ROOT/index.html` but not
`webapps/myWebapp/index.html`?

Thanks

Re: http status 404 - not found

[Karen Goh]

On Mon, 11/19/18, Salil Misra  wrote:

 Subject: Re: http status 404 - not found
 To: users@tomcat.apache.org, karenwo...@yahoo.com
 Date: Monday, November 19, 2018, 9:14 PM
 
 Just a quick check , have you
 saved your view page as a JSP and not as HTML
 ? If its saved as HTML , this might be the
 possible cause.
 
 Thanks.
 
 
 
 On
 Sun, 18 Nov 2018 at 09:31, Karen Goh 
 wrote:
 
 >
 Hello Tomcat user group,
 >
 > I hope that this question is valid cos I
 googled and many related issue
 > like
 this pointed to server problem.
 >
 > Tomcat version : 8.5.24
 > IDE : Eclipse Oxygen
 >
 OS : Windows 10
 >
 >
 Basically, I have created a maven structured web app and
 after right-click
 > my tutorRegister
 page, and the form submitted, http status 404 appeared.
 >
 > This is what appeared
 in my browser :
 >
 > 
 /webApp-hi5/$%7BpageContext.request.contextPath%7D/addTutor
 >
 > I have checked my
 past project and there was no problem in getting the
 > form submitted but when I made the project
 into maven type, I am getting
 > the above
 error.
 >
 >        
 
 action="${pageContext.request.contextPath}/addTutor"
 >
 > Here's my pom.xml
 ;
 >
 >
 4.0.0
 >
 >        
 com.hi5Supreme.web
 >        
 webApp-hi5
 >        
 0.0.1-SNAPSHOT
 >        
 war
 >
 >        
 webApp-hi5 Maven Webapp
 >         
 >
 >
 UTF-8
 >                
 1.8
 >                
 1.8
 >         
 >
 >
 >         
 >                
 webApp-hi5
 >                
 
 >             
    
 >      
 src/main/webapp
 >     
 >     
 >                
 
 >                        
 
 >               
                  
 >
 >
 maven-clean-plugin
 >                           
              3.0.0
 >                           
      
 >           
                      
 >         
                        
 >
 >
 maven-resources-plugin
 >                           
              3.0.2
 >                           
      
 >           
                      
 >
 >
 maven-compiler-plugin
 >                           
              3.7.0
 >                           
      
 >           
                      
 >
 >
 maven-surefire-plugin
 >                           
              2.20.1
 >                           
      
 >           
                      
 >
 >
 maven-war-plugin
 >                           
              3.2.0
 >                           
              
 >                           
             
 webApp-hi5
 >                           
              
 >                           
      
 >           
                      
 >
 >
 maven-install-plugin
 >                           
              2.5.2
 >                           
      
 >           
                      
 >
 >
 maven-deploy-plugin
 >                           
              2.8.2
 >                           
      
 >           
              
 > 
                
 >         
 >         
 >                
 
 >             
           
 javax.servlet.jsp
 >                        
 javax.servlet.jsp-api
 >                        
 2.3.1
 > 
                       
 provided
 > 
                
 >                
 
 >             
           
 javax.servlet
 >                        
 jsp-api
 >                        
 2.0
 >   
              
 >                
 
 >             
            jstl
 >                        
 jstl
 >                        
 provided
 > 
                       
 1.2
 >   
              
 >                 
 >                
 
 >             
           
 org.lazyluke
 >                        
 log4jdbc-remix
 >                        
 0.2.7
 > 
                
 >                
 
 >             
            mysql
 >                        
 mysql-connector-java
 >                        
 8.0.12
 > 
                       
 provided
 > 
                
 >                
 
 >             
           
 javax.servlet
 >                        
 javax.servlet-api
 >                        
 3.1.0
 > 
                       
 provided
 > 
                
 >                
 
 >             
            junit
 >                        
 junit
 >                        
 4.11
 > 
                       
 test
 >     
            
 > 
        
 >
 
 >
 >
 Hope someone can let me know how if I have missed out
 anything.
 >
 >
 Tks.
 >
 >
 >
 >
 >
 -
 > 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: http status 404 - not found

[Salil Misra]

Just a quick check , have you saved your view page as a JSP and not as HTML
? If its saved as HTML , this might be the possible cause.

Thanks.



On Sun, 18 Nov 2018 at 09:31, Karen Goh 
wrote:

> Hello Tomcat user group,
>
> I hope that this question is valid cos I googled and many related issue
> like this pointed to server problem.
>
> Tomcat version : 8.5.24
> IDE : Eclipse Oxygen
> OS : Windows 10
>
> Basically, I have created a maven structured web app and after right-click
> my tutorRegister page, and the form submitted, http status 404 appeared.
>
> This is what appeared in my browser :
>
>  /webApp-hi5/$%7BpageContext.request.contextPath%7D/addTutor
>
> I have checked my past project and there was no problem in getting the
> form submitted but when I made the project into maven type, I am getting
> the above error.
>
>  action="${pageContext.request.contextPath}/addTutor"
>
> Here's my pom.xml ;
>
> 4.0.0
>
> com.hi5Supreme.web
> webApp-hi5
> 0.0.1-SNAPSHOT
> war
>
> webApp-hi5 Maven Webapp
> 
>
> UTF-8
> 1.8
> 1.8
> 
>
>
> 
> webApp-hi5
> 
> 
>   src/main/webapp
> 
> 
> 
> 
> 
>
> maven-clean-plugin
> 3.0.0
> 
> 
> 
>
> maven-resources-plugin
> 3.0.2
> 
> 
>
> maven-compiler-plugin
> 3.7.0
> 
> 
>
> maven-surefire-plugin
> 2.20.1
> 
> 
>
> maven-war-plugin
> 3.2.0
> 
> webApp-hi5
> 
> 
> 
>
> maven-install-plugin
> 2.5.2
> 
> 
>
> maven-deploy-plugin
> 2.8.2
> 
> 
> 
> 
> 
> 
> javax.servlet.jsp
> javax.servlet.jsp-api
> 2.3.1
> provided
> 
> 
> javax.servlet
> jsp-api
> 2.0
> 
> 
> jstl
> jstl
> provided
> 1.2
> 
> 
> 
> org.lazyluke
> log4jdbc-remix
> 0.2.7
> 
> 
> mysql
> mysql-connector-java
> 8.0.12
> provided
> 
> 
> javax.servlet
> javax.servlet-api
> 3.1.0
> provided
> 
> 
> junit
> junit
> 4.11
> test
> 
> 
> 
>
> Hope someone can let me know how if I have missed out anything.
>
> Tks.
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: http status 404 - not found

[Mark Thomas]

On 18/11/2018 04:01, Karen Goh wrote:
> Hello Tomcat user group,
> 
> I hope that this question is valid cos I googled and many related issue like 
> this pointed to server problem.

The question is valid but this is an application problem, not a server
problem.

> Tomcat version : 8.5.24> IDE : Eclipse Oxygen
> OS : Windows 10

Thanks for the OS and Tomcat version information. I'd recommend you
include the version of Java you are using as well. Generally, the Tomcat
version is the most useful, followed by the Java version and then the OS
information.

> Basically, I have created a maven structured web app and after right-click my 
> tutorRegister page, and the form submitted, http status 404 appeared.
> 
> This is what appeared in my browser :
> 
>  /webApp-hi5/$%7BpageContext.request.contextPath%7D/addTutor

OK. Tomcat will decode those %nn sequences before mapping the request to
a servlet so Tomcat will see:

/webApp-hi5/${pageContext.request.contextPath}/addTutor

> I have checked my past project and there was no problem in getting the form 
> submitted but when I made the project into maven type, I am getting the above 
> error.
> 
>action="${pageContext.request.contextPath}/addTutor"

The EL has not been processed. It has been treated as template text.
Since the string does not start with '/' it has been treated as relative
to the current page (which I assume was '/webApp-hi5/something').

You need to find out why the EL in the form isn't being processed as EL.

Things to look at:
- file name
- version declared for web.xml
- the JSP specification and look for "Deactivating EL"

> Here's my pom.xml ;



>   
>   
>   javax.servlet.jsp
>   javax.servlet.jsp-api
>   2.3.1
>   provided
>   

This appears to be relevant given what you'll find in the JSP specification.

Mark

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

Re: http status 404 - not found

[Arjuna Bandara]

Hi,

Can you explain more about the issue and update problem with the console
output?

Was the maven building successful? Try run clean build with ' clean build
-e'. You may have full stack trace.

-
Arjuna


On Sun, 18 Nov 2018 9:31 am Karen Goh,  wrote:

> Hello Tomcat user group,
>
> I hope that this question is valid cos I googled and many related issue
> like this pointed to server problem.
>
> Tomcat version : 8.5.24
> IDE : Eclipse Oxygen
> OS : Windows 10
>
> Basically, I have created a maven structured web app and after right-click
> my tutorRegister page, and the form submitted, http status 404 appeared.
>
> This is what appeared in my browser :
>
>  /webApp-hi5/$%7BpageContext.request.contextPath%7D/addTutor
>
> I have checked my past project and there was no problem in getting the
> form submitted but when I made the project into maven type, I am getting
> the above error.
>
>  action="${pageContext.request.contextPath}/addTutor"
>
> Here's my pom.xml ;
>
> 4.0.0
>
> com.hi5Supreme.web
> webApp-hi5
> 0.0.1-SNAPSHOT
> war
>
> webApp-hi5 Maven Webapp
> 
>
> UTF-8
> 1.8
> 1.8
> 
>
>
> 
> webApp-hi5
> 
> 
>   src/main/webapp
> 
> 
> 
> 
> 
>
> maven-clean-plugin
> 3.0.0
> 
> 
> 
>
> maven-resources-plugin
> 3.0.2
> 
> 
>
> maven-compiler-plugin
> 3.7.0
> 
> 
>
> maven-surefire-plugin
> 2.20.1
> 
> 
>
> maven-war-plugin
> 3.2.0
> 
> webApp-hi5
> 
> 
> 
>
> maven-install-plugin
> 2.5.2
> 
> 
>
> maven-deploy-plugin
> 2.8.2
> 
> 
> 
> 
> 
> 
> javax.servlet.jsp
> javax.servlet.jsp-api
> 2.3.1
> provided
> 
> 
> javax.servlet
> jsp-api
> 2.0
> 
> 
> jstl
> jstl
> provided
> 1.2
> 
> 
> 
> org.lazyluke
> log4jdbc-remix
> 0.2.7
> 
> 
> mysql
> mysql-connector-java
> 8.0.12
> provided
> 
> 
> javax.servlet
> javax.servlet-api
> 3.1.0
> provided
> 
> 
> junit
> junit
> 4.11
> test
> 
> 
> 
>
> Hope someone can let me know how if I have missed out anything.
>
> Tks.
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

http status 404 - not found

[Karen Goh]

Hello Tomcat user group,

I hope that this question is valid cos I googled and many related issue like 
this pointed to server problem.

Tomcat version : 8.5.24
IDE : Eclipse Oxygen
OS : Windows 10

Basically, I have created a maven structured web app and after right-click my 
tutorRegister page, and the form submitted, http status 404 appeared.

This is what appeared in my browser :

 /webApp-hi5/$%7BpageContext.request.contextPath%7D/addTutor

I have checked my past project and there was no problem in getting the form 
submitted but when I made the project into maven type, I am getting the above 
error.

4.0.0

com.hi5Supreme.web
webApp-hi5
0.0.1-SNAPSHOT
war

webApp-hi5 Maven Webapp


UTF-8
1.8
1.8




webApp-hi5
 

  src/main/webapp






maven-clean-plugin
3.0.0




maven-resources-plugin
3.0.2



maven-compiler-plugin
3.7.0



maven-surefire-plugin
2.20.1



maven-war-plugin
3.2.0

webApp-hi5




maven-install-plugin
2.5.2



maven-deploy-plugin
2.8.2






javax.servlet.jsp
javax.servlet.jsp-api
2.3.1
provided


javax.servlet
jsp-api
2.0


jstl
jstl
provided
1.2  



org.lazyluke
log4jdbc-remix
0.2.7


mysql
mysql-connector-java
8.0.12
provided


javax.servlet
javax.servlet-api
3.1.0
provided


junit
junit
4.11
test




Hope someone can let me know how if I have missed out anything.

Tks.




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

Re: How to coustomize error 404 apache tomcat 9.0.6

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Alexandre,

>>> On Apr 25, 2018, at 7:06 PM, Christopher Schultz 
>>> <ch...@christopherschultz.net> wrote:
>>> 
>> Anexandre,
>> 
>>>>> On 4/25/18 6:23 PM, Alexandre Adao wrote: What will be the 
>>>>> easiest way to customize page error 404 running Apache 
>>>>> Tomcat 9.0.6?  I have tried some links such as 
>>>>> https://serverfault.com/questions/254102/custom-error-pages-on-apa
che-
>>
>>>>>
>>>>> 
tomcat
>>>>> 
>>>>> 
>> and didn't work.
>>>>> 
>>>>> I am running on Windows Server 2016 at the moment. My 
>>>>> default directory is: C:\Program Files\Apache Software 
>>>>> Foundation\Tomcat 9.0.6. Which web.xml needs to be
>>>>> changed? ..\conf or ..\weapps ? How can I customize the
>>>>> error page 404?
>> 
>> Do you want to customize the 404 response page for your web 
>> application (e.g. /myapp/no-such-resource) or for the whole 
>> server (e.g. /no-such-context/no-such-resource)?
> On 4/25/18 7:49 PM, Alexandre Adao wrote:> For the whole server...

The easiest thing for you to do is:

C:> CD C:\Program Files\Apache Software Foundation\Tomcat 9.0.6
C:> MKDIR webapps\ROOT
C:> CD webapps\ROOT
C:> MKDIR WEB-INF
C:> COPY CON WEB-INF\web.xml

http://java.sun.com/xml/ns/javaee;
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd;
 version="3.0"
 metadata-complete="true">
  Dummy ROOT context to prevent 400 Bad Request
responses
  
404
/404.html
  

^Z<- That's a CTRL-Z character, to end the here-document

Now, put whatever content you want into 404.html and you are done. If
you like what you have, make it into a WAR file and you can drop it
onto all your running servers.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlrhzvIACgkQHPApP6U8
pFj9LA/+OhtekamX2nv4IfD+K8iYqqrLqpreL/sGumaQ8I+18+R5RUMXN13v0Nfs
A3DZK8ASK9dThZtXg1HnHuFP+F3tFgk50Wt8NIg3CqbS+CI6ozljXjuogXI1vUlB
1ZdRdvAyB79F4k3h9CGPmh10BAuTohR4O1K8//NtW1Ca0JpOIS1ZDYTuj//XQA6N
4be37HOTGCh5+szp8E+wpM4DncHjlOB2AbtCTeNeTmb4KzoJuIYSlJxwWxXV58fc
dRCi0di/uy2DnwS/3KNQp4dyk2qnnr9iwHcfopr+Vb24hvrH+7sLTSaydxZkfoxh
lPY9KfD6asPjfrCZWeT9/scN+iQ4ELnpdB+e/FuQ9BNZQ/fIfSFBFnkpEeMw7qmF
j2A76gViJO+RNhGmDF5kOjOlR9Wy2oYI7/7mnfiqS30SK56so5wZY0eEoF+0W3IE
1GvatccA2l2dJwQzAcEOcUzdrUPRNCK9omfvW0Qil8Rl0l7/h/v+jW72MdN+kZBY
eEatVGdkrYw/qXG/QGc4lbpoe5/6HIzGZ7SmZH8ymoQR/+LyMwOFn5MrRn+dZTpV
QGWddokaz0er3WU7pRRuhWRlHp1GPsYh5X7y2WnJ++R33G0ctksm6q1iCOx4utnr
+yOVqQDhUjphEThWpQwostlj07ejY6wjS5+WjitDkAbB+sjCIxI=
=ytZS
-END PGP SIGNATURE-

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

Re: How to coustomize error 404 apache tomcat 9.0.6

[Alexandre Adao]

For the whole server...

Sent from my iPhone

> On Apr 25, 2018, at 7:06 PM, Christopher Schultz 
> <ch...@christopherschultz.net> wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Anexandre,
> 
>> On 4/25/18 6:23 PM, Alexandre Adao wrote:
>> What will be the easiest way to customize page error 404 running
>> Apache Tomcat 9.0.6?  I have tried some links such as 
>> https://serverfault.com/questions/254102/custom-error-pages-on-apache-
> tomcat
>> 
>> 
> and didn't work.
>> 
>> I am running on Windows Server 2016 at the moment. My default
>> directory is: C:\Program Files\Apache Software Foundation\Tomcat
>> 9.0.6. Which web.xml needs to be changed?  ..\conf or ..\weapps ?
>> How can I customize the error page 404?
> 
> Do you want to customize the 404 response page for your web
> application (e.g. /myapp/no-such-resource) or for the whole server
> (e.g. /no-such-context/no-such-resource)?
> 
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlrhCekACgkQHPApP6U8
> pFgyqA//ZrKXhD6uD+Wp17zBaacL/0pseT6S2vq8oreant04PCcKTpERQeyM0iM5
> mp1K7PiUw5pA5WEQxwAt8L13lT3c2UvnW6EsIhsW9HjF3S/WEoU8csKXdS/m0jbl
> 9KaCPBhz10C1MaMR0IWfGHQkf2dKv7a4GcI75ZpNKLutuyiKGB+K+suTdiuOjV+q
> ZBsEHU5BgD97sAa6IZKCr1Fr0EQgQ/LPCTZzuE0RiZzQPYTW5d3RfVeBkevgoGHF
> fLCTNwjLEQqfBvqCZ5wB14e7LW0ipPXxmOR5/+f1Ka0Qh2KmktTKsQ06jQLc+UTi
> DJUJRkVfBZovh7E3dKPppp5EkrrDLyHI3GuPPPgfa853YkGDx7rJ1+18crqnjKeE
> GI4VoDrM2TSuy4zT+jriJZHrGqIezTuqjZHnwXfCxMmedImalSj1UlokGrly/86U
> XXYgA7QPKrUlgMlgH81e5WJJt9mZSACm4IAYYXml3+5n5EyHlmAXkIQoD0/U2JR3
> 42gn0AuuBtBW2JG/Ry89sVx2PVe8zRfiDul2hDgYHbhP/XVbgBoDKYM9nAr7MshG
> /fyajgCFbaV9Bgtf7Jgydracx34VfzCaeZkyd77cVormnnCriwksGXMzVNjgS8SB
> dhH3QgRiK2WAYiBAGdxdzgE6WrT4wYJZF1NMeyDYdAD2XGvM0Gg=
> =E9Py
> -END PGP SIGNATURE-
> 
> -
> 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: How to coustomize error 404 apache tomcat 9.0.6

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Anexandre,

On 4/25/18 6:23 PM, Alexandre Adao wrote:
> What will be the easiest way to customize page error 404 running
> Apache Tomcat 9.0.6?  I have tried some links such as 
> https://serverfault.com/questions/254102/custom-error-pages-on-apache-
tomcat
>
> 
and didn't work.
> 
> I am running on Windows Server 2016 at the moment. My default
> directory is: C:\Program Files\Apache Software Foundation\Tomcat
> 9.0.6. Which web.xml needs to be changed?  ..\conf or ..\weapps ?
> How can I customize the error page 404?

Do you want to customize the 404 response page for your web
application (e.g. /myapp/no-such-resource) or for the whole server
(e.g. /no-such-context/no-such-resource)?

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlrhCekACgkQHPApP6U8
pFgyqA//ZrKXhD6uD+Wp17zBaacL/0pseT6S2vq8oreant04PCcKTpERQeyM0iM5
mp1K7PiUw5pA5WEQxwAt8L13lT3c2UvnW6EsIhsW9HjF3S/WEoU8csKXdS/m0jbl
9KaCPBhz10C1MaMR0IWfGHQkf2dKv7a4GcI75ZpNKLutuyiKGB+K+suTdiuOjV+q
ZBsEHU5BgD97sAa6IZKCr1Fr0EQgQ/LPCTZzuE0RiZzQPYTW5d3RfVeBkevgoGHF
fLCTNwjLEQqfBvqCZ5wB14e7LW0ipPXxmOR5/+f1Ka0Qh2KmktTKsQ06jQLc+UTi
DJUJRkVfBZovh7E3dKPppp5EkrrDLyHI3GuPPPgfa853YkGDx7rJ1+18crqnjKeE
GI4VoDrM2TSuy4zT+jriJZHrGqIezTuqjZHnwXfCxMmedImalSj1UlokGrly/86U
XXYgA7QPKrUlgMlgH81e5WJJt9mZSACm4IAYYXml3+5n5EyHlmAXkIQoD0/U2JR3
42gn0AuuBtBW2JG/Ry89sVx2PVe8zRfiDul2hDgYHbhP/XVbgBoDKYM9nAr7MshG
/fyajgCFbaV9Bgtf7Jgydracx34VfzCaeZkyd77cVormnnCriwksGXMzVNjgS8SB
dhH3QgRiK2WAYiBAGdxdzgE6WrT4wYJZF1NMeyDYdAD2XGvM0Gg=
=E9Py
-END PGP SIGNATURE-

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

How to coustomize error 404 apache tomcat 9.0.6

[Alexandre Adao]

Hello,

What will be the easiest way to customize page error 404 running Apache
Tomcat 9.0.6?  I have tried some links such as
https://serverfault.com/questions/254102/custom-error-pages-on-apache-tomcat
and didn't work.

I am running on Windows Server 2016 at the moment. My default directory is:
C:\Program Files\Apache Software Foundation\Tomcat 9.0.6. Which web.xml
needs to be changed?  ..\conf or ..\weapps ?  How can I customize the error
page 404?

Thanks,

--Alex Adao

Re: Tomcat throwing 404 error after modifying context.xml

[M. Manna]

Have you read what resource definitions mean from -
https://tomcat.apache.org/tomcat-8.5-doc/config/context.html ?

On 22 February 2018 at 08:32, Howlader, Aakash [GTSUS Non-J] <
ahowl...@its.jnj.com> wrote:

> Hello,
>
> The jdbc url  "url="jdbc:postgresql://itsusralsp06829:5432/spectra"
> points to a postgre db in another host.
> We tried to modify the maxActive parameter. The other parameters were left
> untouched.
>
>
> This is what the property was in the original context.xml
>
> >  > type="javax.sql.DataSource" maxActive="50" maxIdle="30"
>  > maxWait="1" username="saevdcep" password="xx"
>  > driverClassName="org.postgresql.Driver"
>  > url="jdbc:postgresql://itsusralsp06829:5432/spectra"/>
>  >
>  >   > type="javax.sql.DataSource" maxActive="50" maxIdle="30"
>  > maxWait="1" username="saevdcep" password="xxx"
>  > driverClassName="org.postgresql.Driver"
>  > url="jdbc:postgresql://itsusralsp06829:5432/evidencesearch"/>
>
>
> This is the change we made.
>
> >  > type="javax.sql.DataSource" maxActive="2" maxIdle="30"
>  > maxWait="1" username="saevdcep" password="xx"
>  > driverClassName="org.postgresql.Driver"
>  > url="jdbc:postgresql://itsusralsp06829:5432/spectra"/>
>  >
>  >   > type="javax.sql.DataSource" maxActive="2" maxIdle="30"
>  > maxWait="1" username="saevdcep" password="xxx"
>  > driverClassName="org.postgresql.Driver"
>  > url="jdbc:postgresql://itsusralsp06829:5432/evidencesearch"/>
>
>
> Not sure why the jdbc url should change. Could you shed some light on this?
>
>
> -Original Message-
> From: M. Manna [mailto:manme...@gmail.com]
> Sent: Thursday, February 22, 2018 4:09 AM
> To: Tomcat Users List <users@tomcat.apache.org>
> Cc: DL-MD-R <DL-HCSUS-MD-R@its.jnj.com>
> Subject: [EXTERNAL] Re: Tomcat throwing 404 error after modifying
> context.xml
>
> Your jdbc url and context path have changed. Have you updated how and
> where you are requesting it? 404 means Not Found. So your requesting for
> something non-existent.
> Please chill and confirm.
>
> On Wed, 21 Feb 2018 at 22:32, Howlader, Aakash [GTSUS Non-J] <
> ahowl...@its.jnj.com> wrote:
>
> > Hello,
> >
> > We were facing a "pool error timeout waiting for idle object" issue.
> > To replicate that in lower environments and perform tests, we tried to
> > make changes to the contex.xml file located under the conf directory
> > of tomcat.
> > The path is /apps/apache-tomcat-7.0.67/conf/context.xml
> >
> > The properties we were modifying are given below .
> >
> > >  > > type="javax.sql.DataSource" maxActive="50" maxIdle="30"
> > > maxWait="1" username="saevdcep" password="xx"
> > > driverClassName="org.postgresql.Driver"
> > > url="jdbc:postgresql://itsusralsp06829:5432/spectra"/>
> > >
> > >  > > type="javax.sql.DataSource" maxActive="50" maxIdle="30"
> > > maxWait="1" username="saevdcep" password="xxx"
> > > driverClassName="org.postgresql.Driver"
> > > url="jdbc:postgresql://itsusralsp06829:5432/evidencesearch"/>
> >
> > However, on restarting the tomcat server after making changes to
> > values in these, the application is throwing a 404: Resource not Found
> > error. The tomcat server is up and running but on hitting the
> > application URL, we are getting the 404 error.
> >
> > We even tried restoring the context.xml file to its original values
> > but that did not seem to  make a difference.
> >
> > Can you  please let us know what steps we need to follow in order to
> > be able to make modifications to the file and perform our tests?
> >
> > Best Regards,
> > Aakash
> >
> >
>

RE: Tomcat throwing 404 error after modifying context.xml

[Howlader, Aakash [GTSUS Non-J]]

Hello,

The jdbc url  "url="jdbc:postgresql://itsusralsp06829:5432/spectra" points to a 
postgre db in another host. 
We tried to modify the maxActive parameter. The other parameters were left 
untouched.


This is what the property was in the original context.xml

> type="javax.sql.DataSource" maxActive="50" maxIdle="30"
 > maxWait="1" username="saevdcep" password="xx"
 > driverClassName="org.postgresql.Driver"
 > url="jdbc:postgresql://itsusralsp06829:5432/spectra"/>
 >
 >  type="javax.sql.DataSource" maxActive="50" maxIdle="30"
 > maxWait="1" username="saevdcep" password="xxx"
 > driverClassName="org.postgresql.Driver"
 > url="jdbc:postgresql://itsusralsp06829:5432/evidencesearch"/>


This is the change we made.

> type="javax.sql.DataSource" maxActive="2" maxIdle="30"
 > maxWait="1" username="saevdcep" password="xx"
 > driverClassName="org.postgresql.Driver"
 > url="jdbc:postgresql://itsusralsp06829:5432/spectra"/>
 >
 >  type="javax.sql.DataSource" maxActive="2" maxIdle="30"
 > maxWait="1" username="saevdcep" password="xxx"
 > driverClassName="org.postgresql.Driver"
 > url="jdbc:postgresql://itsusralsp06829:5432/evidencesearch"/>


Not sure why the jdbc url should change. Could you shed some light on this?


-Original Message-
From: M. Manna [mailto:manme...@gmail.com] 
Sent: Thursday, February 22, 2018 4:09 AM
To: Tomcat Users List <users@tomcat.apache.org>
Cc: DL-MD-R <DL-HCSUS-MD-R@its.jnj.com>
Subject: [EXTERNAL] Re: Tomcat throwing 404 error after modifying context.xml

Your jdbc url and context path have changed. Have you updated how and where you 
are requesting it? 404 means Not Found. So your requesting for something 
non-existent.
Please chill and confirm.

On Wed, 21 Feb 2018 at 22:32, Howlader, Aakash [GTSUS Non-J] < 
ahowl...@its.jnj.com> wrote:

> Hello,
>
> We were facing a "pool error timeout waiting for idle object" issue.
> To replicate that in lower environments and perform tests, we tried to 
> make changes to the contex.xml file located under the conf directory 
> of tomcat.
> The path is /apps/apache-tomcat-7.0.67/conf/context.xml
>
> The properties we were modifying are given below .
>
> >  > type="javax.sql.DataSource" maxActive="50" maxIdle="30"
> > maxWait="1" username="saevdcep" password="xx"
> > driverClassName="org.postgresql.Driver"
> > url="jdbc:postgresql://itsusralsp06829:5432/spectra"/>
> >
> >  > type="javax.sql.DataSource" maxActive="50" maxIdle="30"
> > maxWait="1" username="saevdcep" password="xxx"
> > driverClassName="org.postgresql.Driver"
> > url="jdbc:postgresql://itsusralsp06829:5432/evidencesearch"/>
>
> However, on restarting the tomcat server after making changes to 
> values in these, the application is throwing a 404: Resource not Found 
> error. The tomcat server is up and running but on hitting the 
> application URL, we are getting the 404 error.
>
> We even tried restoring the context.xml file to its original values 
> but that did not seem to  make a difference.
>
> Can you  please let us know what steps we need to follow in order to 
> be able to make modifications to the file and perform our tests?
>
> Best Regards,
> Aakash
>
>

Re: Tomcat throwing 404 error after modifying context.xml

[M. Manna]

Your jdbc url and context path have changed. Have you updated how and where
you are requesting it? 404 means Not Found. So your requesting for
something non-existent.
Please chill and confirm.

On Wed, 21 Feb 2018 at 22:32, Howlader, Aakash [GTSUS Non-J] <
ahowl...@its.jnj.com> wrote:

> Hello,
>
> We were facing a "pool error timeout waiting for idle object" issue.
> To replicate that in lower environments and perform tests, we tried to
> make changes to the contex.xml file located under the conf directory of
> tomcat.
> The path is /apps/apache-tomcat-7.0.67/conf/context.xml
>
> The properties we were modifying are given below .
>
> >  > type="javax.sql.DataSource" maxActive="50" maxIdle="30"
> > maxWait="1" username="saevdcep" password="xx"
> > driverClassName="org.postgresql.Driver"
> > url="jdbc:postgresql://itsusralsp06829:5432/spectra"/>
> >
> >  > type="javax.sql.DataSource" maxActive="50" maxIdle="30"
> > maxWait="1" username="saevdcep" password="xxx"
> > driverClassName="org.postgresql.Driver"
> > url="jdbc:postgresql://itsusralsp06829:5432/evidencesearch"/>
>
> However, on restarting the tomcat server after making changes to values in
> these, the application is throwing a 404: Resource not Found error. The
> tomcat server is up and running but on hitting the application URL, we are
> getting the 404 error.
>
> We even tried restoring the context.xml file to its original values but
> that did not seem to  make a difference.
>
> Can you  please let us know what steps we need to follow in order to be
> able to make modifications to the file and perform our tests?
>
> Best Regards,
> Aakash
>
>

Tomcat throwing 404 error after modifying context.xml

[Howlader, Aakash [GTSUS Non-J]]

Hello,

We were facing a "pool error timeout waiting for idle object" issue.
To replicate that in lower environments and perform tests, we tried to make 
changes to the contex.xml file located under the conf directory of tomcat.
The path is /apps/apache-tomcat-7.0.67/conf/context.xml

The properties we were modifying are given below .

>  type="javax.sql.DataSource" maxActive="50" maxIdle="30"
> maxWait="1" username="saevdcep" password="xx"
> driverClassName="org.postgresql.Driver"
> url="jdbc:postgresql://itsusralsp06829:5432/spectra"/>
>
>  type="javax.sql.DataSource" maxActive="50" maxIdle="30"
> maxWait="1" username="saevdcep" password="xxx"
> driverClassName="org.postgresql.Driver"
> url="jdbc:postgresql://itsusralsp06829:5432/evidencesearch"/>

However, on restarting the tomcat server after making changes to values in 
these, the application is throwing a 404: Resource not Found error. The tomcat 
server is up and running but on hitting the application URL, we are getting the 
404 error.

We even tried restoring the context.xml file to its original values but that 
did not seem to  make a difference.

Can you  please let us know what steps we need to follow in order to be able to 
make modifications to the file and perform our tests?

Best Regards,
Aakash

Re: asgard tomcat application 404

[Simon De Uvarow]

I don't know about Spring, but according to your exception, and my short
experience, could be a database connection issue.

grails.web.context.GrailsContextLoaderError initializing Grails: Error
creating bean with name 'pluginManager' defined in ServletContext resource
*[/WEB-INF/applicationContext.**xml]*: Invocation of init method failed;
nested exception is java.lang.NullPointerException: Cannot invoke method
getAt() on null object

Usually in the context file is where u define the connection pool, and JPA
stuff.
The null pointer exception makes me imagine that a DB connection, or entity
manager, couldn't be created.

Maybe the asgard database was not created as expected by the app?

Hope it helps,


"No olvides, no traiciones, lo que llevas bien dentro de ti. No olvides, no
traiciones, lo que siempre te ha hecho vivir."

On Tue, Feb 20, 2018 at 12:06 AM, Tim Dunphy  wrote:

> Ok guys. Got it! Thanks for your input. I'll follow up with the Asgard
> list, assuming I can find it.
>
> Thanks
>
> On Fri, Feb 16, 2018 at 2:40 PM, Olaf Kock  wrote:
>
> >
> > On 15.02.2018 23:39, Tim Dunphy wrote:
> >
> >> I'm trying to get Netflix Asgard tomcat app working. I'm using tomcat 9.
> >> I'm using windows.
> >> [...]
> >>
> > Tomcat is about as much involved in this as is Windows. To second
> > Christopher's OT answer: This is a problem of the deployed application,
> not
> > of Tomcat. You should look for help in the Asgard community. Tomcat
> doesn't
> > use spring, thus there's not even common ground.
> >
> > Olaf
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >
>
>
> --
> GPG me!!
>
> gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
>