Re: Catalina PID file

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rafael,

On 4/23/20 17:18, Rafael Oliveira wrote:
> I does not happen every time, but it happens, actually it happened
> twice during a couple of deployments and only in one instance of
> several that I have.
>
> I could not reproduce in a safe and close environment, I got this
> error in a server with multiple users and multiple tasks and
> concurred environment.
>
> The point is raise a question is this echo $! > "CATALINA_PID" the
> best approach to get the PID?

It's literally the only way to do it.

$! doesn't get you the PID of some random other process that was
recently started. It's exactly what it says it is: the PID of the last
process that was backgrounded by the currently-executing script.

If your pid-file contains the wrong PID, it's probably because
something overwrite overwrote it after it was initially-generated.

If you try to start Tomcat twice, for example, like this:

$ CATALINA_HOME/bin/startup.sh
[...]
$ cat $CATALINA_PID
1234
$ CATALINA_HOME/bin/startup.sh
[...]
$ cat $CATALINA_PID
2345
$ ps -ef | grep "catalina.base=$CATALINA_HOME"
1234

The startup script will always overwrite the PID file because it can't
tell if it's going to fail (which it will, since the shutdown port is
already bound to the first-launched instance).

In the case above, the PID-file is clobbered by the second process
while the first process continues to run (and be the correct process
id). There isn't much to be done about that without resorting to
drastic measures, such as having Tomcat write its own PID file after
it starts up (enough), and getting the PID from Java isn't
super-straightforward until Java 9. :(

- -chris

> Em qui., 23 de abr. de 2020 às 02:44, calder
>  escreveu:
>
>> On Wed, Apr 22, 2020 at 11:34 AM Rafael Oliveira
>>  wrote:
>>> Hello everyone during some tests where I ran in my local
>>> environment I
>> came
>>> across an odd behavior on tomcat start
>>>
>>> During the start process catalina.sh script create a new PID
>>> file using
>> the
>>> following statement *echo $! > "CATALINA_PID"*
>>>
>>> $! *Expands to the process **ID** of the job most recently
>>> placed into
>> the
>>> background,* whether executed as an asynchronous command or
>>> using the bg builtin
>>
>> Correct.
>>
>>> The PID number inside the PID file is different of the tomcat
>>> process
>>
>> Not on my installations - using "./catalina.sh start  >
>> startup.txt 2>&1"
>>
>> user@stimpy:~/bin/apache-tomcat-9.0.26/bin> cat cat-pid 8732
>> user@stimpy:~/bin/apache-tomcat-9.0.26/bin> ps -aux | grep
>> tomcat user8732  1.3  0.2 23279772 161408 pts/1 Sl   00:28
>> 0:05 /usr/lib64/jvm/java/bin/java
>> -Djava.util.logging.config.file=/home/user/bin/apache-tomcat-9.0.26/
>>
>>
>>
... and using "startup.sh"
>>
>> user@stimpy:~/bin/apache-tomcat-9.0.26/bin> cat cat-pid 9861
>> user@stimpy:~/bin/apache-tomcat-9.0.26/bin> ps -aux | grep
>> tomcat user   9861 18.4  0.2 23277724 148168 pts/1 Sl   00:37
>> 0:04 /usr/lib64/jvm/java/bin/java
>> -Djava.util.logging.config.file=/home/user/bin/apache-tomcat-9.0.26/
>>
>>>
>>
started which I could verify with:
>>> ps -ef  | grep 'catalina.base=$CATALINA_HOME'
>>
>> ??
>>
>> -
>>
>>
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6iThsACgkQHPApP6U8
pFjhHBAAiO2x2N360ZE93w7e6OOYGG/fhyJJELiSkRuL5EQ0nmuK4ogFNvA6elQi
9Es1piIs7u5/AaSR/1eUcpoSGCCJAPHBC1oFyl9n4mWuL1+uKjGfGIPH2y3v8UEo
SNJXSZHU3EG9jLPp+txY3oHO/ugDvjNowKlXn3wsrQxa2WS+zN4gruvGMWBg6D8u
jdRv8avHfovIlTXGfyVj0N/4d5eUD25hw8/zekddntdjVt1B2G0eq8y29fy8uQQV
Xkvzyer5ejzK+iE8PfMfn8cNHgmM0yG9ZCKdBDMijpq0PeDhtcsElHvSfx0FAlpr
PPw/wQk3yZErBtNEm/ThiPPsT4v+Q6oir13hhbFEPiur1y9LlyFxYiQP4U95Vgmp
UAHdSqjyl16QFn215j1Mfljjep7lKr21F9aOVgH8V3j5VD0FxXYzcJNrItW4uRx4
jik9IuCD/z8IHTq10eI+G+peeCKt9t64byYZVphNq4gIWjrjFr3ZVitFuqGEzqqc
wipKgrmf+iRidygEubak3JhM/0Go4YdkVCDFcoT56XYYs27XTUYeDGBAvL/uo7/O
/vkIGiHxv0f5+N2OlI9Hv5j04m02CKRTiZMvDdS72u6dT2sGdKuhZbLR8eRs1ZAD
X9uhJ7jCkuHFgPRC5p5IZMNOl6qn7RGIyZUT+NGoaMpbTaaRcJ4=
=xf+8
-END PGP SIGNATURE-

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

Re: Strange behavior when deploying new war

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

John,

On 4/23/20 15:19, John Larsen wrote:
> Ah doing ROOT.war is my pet peeve. I find this bad practice. Its
> nice to have ROOT especially when the developer insists theres
> something wrong with tomcat when really its their webapp. Having
> ROOT intact, can show that by removing their webapp and tomcat
> works.

But you are replacing the application with context path "" (empty, not
"/") with your own, anyway. It doesn't really matter HOW you do it.

If you want to demonstrate that Tomcat works without the offending
application, just remove ROOT.war and ... you are done.

> As for "/" vs "" - not sure that would solve the problem - i mean
> logically it doesnt make sense, but I will give it a try.

I'm not sure if it will fix your problem (unlikely, as your problem
was with deployment mechanics and not anything Tomcat was doing), but
the proper context path for the ROOT web application is "" (empty),
not "/".

- -chris

> On Thu, Apr 23, 2020 at 1:15 PM Mark Thomas 
> wrote:
>
>> On 23/04/2020 20:10, John Larsen wrote:
>>> Ok so my next question is how to handle this better? The goal
>>> here is so that one does not have to enter /webappName/ on the
>>> end of the domain. We use the context to tell Tomcat which
>>> webapp to load instead of ROOT.
>>
>> Name the file "ROOT.war"
>>
>> And if you need some sort of identifier on the file:
>> "ROOT##alnomost-any-text-you-like.war"
>>
>> In the meantime, try specifying the path in server.xml as ""
>> rather than "/".
>>
>> Mark
>>
>>
>>>
>>> John Larsen
>>>
>>>
>>> On Thu, Apr 23, 2020 at 12:47 PM Christopher Schultz <
>>> ch...@christopherschultz.net> wrote:
>>>
>>> John,
>>>
>>> On 4/23/20 14:38, John Larsen wrote:
>> New tomcats 9.0.34 seems to fail when uploading new war
>> when theres a context in server.xml pointing to the
>> particular exploded war. Says 'The main resource set
>> specified is not valid.' It's like hot deploy is deleting
>> the old webapp and restarting tomcat?
>>
>> >
>> docBase="/home/some/path/tomcat/webapps/webappName">
>>
>> 
>>
>> To work around this one has to comment out the above
>> context, start tomcat so the war will deploy, uncomment
>> and then restart tomcat again.
>>>
>>> Is there a compelling reason to have  in your
>>> conf/server.xml file at all? It sounds like it's not doing
>>> anything for you; indeed it it giving you a headache.
>>>
>>> -chris

 ---
- --


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


>>>
>>
>>
>> -
>>
>>
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6iSx8ACgkQHPApP6U8
pFgwcxAAj6Z71r+e81m1zAKvGp8Mdxe541xNAK3FiFtLaDa/y9kwiiSXj4/3rVZi
rEGulP0jw3VKufN4yBnExYY6Z+Stt4XCEQPqvi+jR20Dt7lmQBYI6d+JkBDp6hUp
KjC9LNi2YfIKXLfbogAK7nUkjXVNEdNqagtJBLhuBFO3Jj8kN2Pl/VU5FRgfPUZX
Y63p+dvDfUjLG5XWPorcBa3jAkB1qhV5kCrhLSeSPuRAmz6P9KzorFU3dljE+4xb
Fhw0kT7Cg20Vb+1TAsEqr3TkkDFNXK1uGTmEGAiKZXIoYB6UeCTA+/OOpcC05uow
G/9KVji/KlItYlMmlxMaDPw5mEm9nReXAVmRZPxm7hi2ULr3l6K2/FPg1J++0/cl
za2wvCyK1Hye1hvgnuPT3Ae9PsdqWnYlNiQkATks/5Y+xBLOM0ShScW9aCaMyLSl
WpNazM9Mtgu3JF74WQEIzRQAXo9IWr1klpRv9pR+lLSAwOHk0r4YvOvQg2F5/XL4
NdLo3ojpMm2eyUoc5n1/yWGYQTDyi4YNAcUaIf1ObFnfSIrrFVvKxtZA2uSllZ4r
5WoPbF1zhM+eYzDSIoLeJRQpuifiZt+Trsq1AWiL8oaoNTvMCAOg7DnD/cQ+P5tK
s1wP64dr7N6H04aElWzwkT3OFOod4ZaoQ0Pm0j1+UR4pj781pvo=
=qdgA
-END PGP SIGNATURE-

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

Re: Strange behavior when deploying new war

[John Larsen]

Turns out the developer was deleting the app dir along with war and
restarting.

John

On Thu, Apr 23, 2020 at 1:19 PM John Larsen 
wrote:

> Ah doing ROOT.war is my pet peeve. I find this bad practice. Its nice to
> have ROOT especially when the developer insists theres something wrong with
> tomcat when really its their webapp. Having ROOT intact, can show that by
> removing their webapp and tomcat works.
>
> As for "/" vs "" - not sure that would solve the problem - i mean
> logically it doesnt make sense, but I will give it a try.
>
> John Larsen
>
>
> On Thu, Apr 23, 2020 at 1:15 PM Mark Thomas  wrote:
>
>> On 23/04/2020 20:10, John Larsen wrote:
>> > Ok so my next question is how to handle this better? The goal here is so
>> > that one does not have to enter /webappName/ on the end of the domain.
>> > We use the context to tell Tomcat which webapp to load instead of ROOT.
>>
>> Name the file "ROOT.war"
>>
>> And if you need some sort of identifier on the file:
>> "ROOT##alnomost-any-text-you-like.war"
>>
>> In the meantime, try specifying the path in server.xml as "" rather than
>> "/".
>>
>> Mark
>>
>>
>> >
>> > John Larsen
>> >
>> >
>> > On Thu, Apr 23, 2020 at 12:47 PM Christopher Schultz <
>> > ch...@christopherschultz.net> wrote:
>> >
>> > John,
>> >
>> > On 4/23/20 14:38, John Larsen wrote:
>>  New tomcats 9.0.34 seems to fail when uploading new war when theres
>>  a context in server.xml pointing to the particular exploded war.
>>  Says 'The main resource set specified is not valid.' It's like hot
>>  deploy is deleting the old webapp and restarting tomcat?
>> 
>>  > 
>>  docBase="/home/some/path/tomcat/webapps/webappName">
>> 
>>  
>> 
>>  To work around this one has to comment out the above context, start
>>  tomcat so the war will deploy, uncomment and then restart tomcat
>>  again.
>> >
>> > Is there a compelling reason to have  in your conf/server.xml
>> > file at all? It sounds like it's not doing anything for you; indeed it
>> > it giving you a headache.
>> >
>> > -chris
>> >>
>> >> -
>> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> >> For additional commands, e-mail: users-h...@tomcat.apache.org
>> >>
>> >>
>> >
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>> --
​
John Larsen
__

   

Re: Catalina PID file

[Rafael Oliveira]

I does not happen every time, but it happens, actually it happened twice
during a couple of deployments and only in one instance of several that I
have.

I could not reproduce in a safe and close environment, I got this error in
a server with multiple users and multiple tasks and concurred environment.

The point is raise a question is this echo $! > "CATALINA_PID" the best
approach to get the PID?

KR,
Rafael

Em qui., 23 de abr. de 2020 às 02:44, calder 
escreveu:

> On Wed, Apr 22, 2020 at 11:34 AM Rafael Oliveira 
> wrote:
> > Hello everyone during some tests where I ran in my local environment I
> came
> > across an odd behavior on tomcat start
> >
> > During the start process catalina.sh script create a new PID file using
> the
> > following statement
> > *echo $! > "CATALINA_PID"*
> >
> > $! *Expands to the process **ID** of the job most recently placed into
> the
> > background,* whether executed as an asynchronous command or using the bg
> >  builtin
>
> Correct.
>
> > The PID number inside the PID file is different of the tomcat process
>
> Not on my installations - using "./catalina.sh start  > startup.txt 2>&1"
>
> user@stimpy:~/bin/apache-tomcat-9.0.26/bin> cat cat-pid
> 8732
> user@stimpy:~/bin/apache-tomcat-9.0.26/bin> ps -aux | grep tomcat
> user8732  1.3  0.2 23279772 161408 pts/1 Sl   00:28   0:05
> /usr/lib64/jvm/java/bin/java
> -Djava.util.logging.config.file=/home/user/bin/apache-tomcat-9.0.26/
>
> ... and using "startup.sh"
>
> user@stimpy:~/bin/apache-tomcat-9.0.26/bin> cat cat-pid
> 9861
> user@stimpy:~/bin/apache-tomcat-9.0.26/bin> ps -aux | grep tomcat
> user   9861 18.4  0.2 23277724 148168 pts/1 Sl   00:37   0:04
> /usr/lib64/jvm/java/bin/java
> -Djava.util.logging.config.file=/home/user/bin/apache-tomcat-9.0.26/
>
> > started which I could verify with:
> > ps -ef  | grep 'catalina.base=$CATALINA_HOME'
>
> ??
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Strange behavior when deploying new war

[John Larsen]

Ah doing ROOT.war is my pet peeve. I find this bad practice. Its nice to
have ROOT especially when the developer insists theres something wrong with
tomcat when really its their webapp. Having ROOT intact, can show that by
removing their webapp and tomcat works.

As for "/" vs "" - not sure that would solve the problem - i mean logically
it doesnt make sense, but I will give it a try.

John Larsen


On Thu, Apr 23, 2020 at 1:15 PM Mark Thomas  wrote:

> On 23/04/2020 20:10, John Larsen wrote:
> > Ok so my next question is how to handle this better? The goal here is so
> > that one does not have to enter /webappName/ on the end of the domain.
> > We use the context to tell Tomcat which webapp to load instead of ROOT.
>
> Name the file "ROOT.war"
>
> And if you need some sort of identifier on the file:
> "ROOT##alnomost-any-text-you-like.war"
>
> In the meantime, try specifying the path in server.xml as "" rather than
> "/".
>
> Mark
>
>
> >
> > John Larsen
> >
> >
> > On Thu, Apr 23, 2020 at 12:47 PM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > John,
> >
> > On 4/23/20 14:38, John Larsen wrote:
>  New tomcats 9.0.34 seems to fail when uploading new war when theres
>  a context in server.xml pointing to the particular exploded war.
>  Says 'The main resource set specified is not valid.' It's like hot
>  deploy is deleting the old webapp and restarting tomcat?
> 
>   
>  docBase="/home/some/path/tomcat/webapps/webappName">
> 
>  
> 
>  To work around this one has to comment out the above context, start
>  tomcat so the war will deploy, uncomment and then restart tomcat
>  again.
> >
> > Is there a compelling reason to have  in your conf/server.xml
> > file at all? It sounds like it's not doing anything for you; indeed it
> > it giving you a headache.
> >
> > -chris
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Strange behavior when deploying new war

[Mark Thomas]

On 23/04/2020 20:10, John Larsen wrote:
> Ok so my next question is how to handle this better? The goal here is so
> that one does not have to enter /webappName/ on the end of the domain.
> We use the context to tell Tomcat which webapp to load instead of ROOT.

Name the file "ROOT.war"

And if you need some sort of identifier on the file:
"ROOT##alnomost-any-text-you-like.war"

In the meantime, try specifying the path in server.xml as "" rather than
"/".

Mark


>
> John Larsen
>
>
> On Thu, Apr 23, 2020 at 12:47 PM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
> John,
> 
> On 4/23/20 14:38, John Larsen wrote:
 New tomcats 9.0.34 seems to fail when uploading new war when theres
 a context in server.xml pointing to the particular exploded war.
 Says 'The main resource set specified is not valid.' It's like hot
 deploy is deleting the old webapp and restarting tomcat?

 >>>
 docBase="/home/some/path/tomcat/webapps/webappName">

 

 To work around this one has to comment out the above context, start
 tomcat so the war will deploy, uncomment and then restart tomcat
 again.
> 
> Is there a compelling reason to have  in your conf/server.xml
> file at all? It sounds like it's not doing anything for you; indeed it
> it giving you a headache.
> 
> -chris
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>


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

Re: Strange behavior when deploying new war

[John Larsen]

Ok so my next question is how to handle this better? The goal here is so
that one does not have to enter /webappName/ on the end of the domain.
We use the context to tell Tomcat which webapp to load instead of ROOT.

John Larsen


On Thu, Apr 23, 2020 at 12:47 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> John,
>
> On 4/23/20 14:38, John Larsen wrote:
> > New tomcats 9.0.34 seems to fail when uploading new war when theres
> > a context in server.xml pointing to the particular exploded war.
> > Says 'The main resource set specified is not valid.' It's like hot
> > deploy is deleting the old webapp and restarting tomcat?
> >
> >  >
> > docBase="/home/some/path/tomcat/webapps/webappName">
> >
> > 
> >
> > To work around this one has to comment out the above context, start
> > tomcat so the war will deploy, uncomment and then restart tomcat
> > again.
>
> Is there a compelling reason to have  in your conf/server.xml
> file at all? It sounds like it's not doing anything for you; indeed it
> it giving you a headache.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6h4pwACgkQHPApP6U8
> pFgkhw/7BGcgqAHCvwsp9n/ZaO1R9IvWNI2bYaznY/bkrhLjuDMFhcg7AFUUjBR3
> EITRLM5MyBHf1Uo0mdRwVQxkGbpgbgctJ4cdFY+B/cuPZoqNt26xmQO3CW3J8SFO
> 7ij5YDos5wIeXBhueQdT9blMFgLAQ/d6tkyRqQSazZlMs5rnXRUcKhU8QLgRXSF0
> 431I3/vQnzekM4eHA8jTe23zPkOVHOfF+LEtWSlVVif+7DaisrKw8DVR62mhrO/U
> 3IpPT8xO8Hwj3wglSEslbMV2dIVlUBzLrrMOlXxmkPdbXEZHJEatGoqC35vsJAq4
> Jxp7gbueSTZZKeFaq6nYbV2wwQo4uE5jU95hVe21EMqtFWm+Kx6fzRIqGkcph9IT
> A0HYxdi8J61NMMjHkwvaBhHBQscSq5N2P3uPi6WMMxDxKr2TrlggoP+9JfMaLmgP
> Z+HIdFB05QxXKJC28LuYbY2LGO87jWl0IHNsV+5/Y0TJDXzaZuLxLPRWTDfzCHkd
> d4xknKyfOd+GnZbThtmPSPPX9uZxBc6Yvb77vbjCKWhbtKPSknQrwWoIykQHLwgX
> Xghl3asjpDm5nD+ZPEKYZKeEsQVfvGGy1BFv+DncV1RVea0gEhMYlNqv7pUQCyS9
> 6DUNysW7ONkOkdit48W0tnF6xc5Wgzf6hUY8knAexH/LB810TbQ=
> =GVSH
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Strange behavior when deploying new war

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

John,

On 4/23/20 14:38, John Larsen wrote:
> New tomcats 9.0.34 seems to fail when uploading new war when theres
> a context in server.xml pointing to the particular exploded war.
> Says 'The main resource set specified is not valid.' It's like hot
> deploy is deleting the old webapp and restarting tomcat?
>
> 
> docBase="/home/some/path/tomcat/webapps/webappName">
>
> 
>
> To work around this one has to comment out the above context, start
> tomcat so the war will deploy, uncomment and then restart tomcat
> again.

Is there a compelling reason to have  in your conf/server.xml
file at all? It sounds like it's not doing anything for you; indeed it
it giving you a headache.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6h4pwACgkQHPApP6U8
pFgkhw/7BGcgqAHCvwsp9n/ZaO1R9IvWNI2bYaznY/bkrhLjuDMFhcg7AFUUjBR3
EITRLM5MyBHf1Uo0mdRwVQxkGbpgbgctJ4cdFY+B/cuPZoqNt26xmQO3CW3J8SFO
7ij5YDos5wIeXBhueQdT9blMFgLAQ/d6tkyRqQSazZlMs5rnXRUcKhU8QLgRXSF0
431I3/vQnzekM4eHA8jTe23zPkOVHOfF+LEtWSlVVif+7DaisrKw8DVR62mhrO/U
3IpPT8xO8Hwj3wglSEslbMV2dIVlUBzLrrMOlXxmkPdbXEZHJEatGoqC35vsJAq4
Jxp7gbueSTZZKeFaq6nYbV2wwQo4uE5jU95hVe21EMqtFWm+Kx6fzRIqGkcph9IT
A0HYxdi8J61NMMjHkwvaBhHBQscSq5N2P3uPi6WMMxDxKr2TrlggoP+9JfMaLmgP
Z+HIdFB05QxXKJC28LuYbY2LGO87jWl0IHNsV+5/Y0TJDXzaZuLxLPRWTDfzCHkd
d4xknKyfOd+GnZbThtmPSPPX9uZxBc6Yvb77vbjCKWhbtKPSknQrwWoIykQHLwgX
Xghl3asjpDm5nD+ZPEKYZKeEsQVfvGGy1BFv+DncV1RVea0gEhMYlNqv7pUQCyS9
6DUNysW7ONkOkdit48W0tnF6xc5Wgzf6hUY8knAexH/LB810TbQ=
=GVSH
-END PGP SIGNATURE-

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

Re: Tomcat Upgrade Issue from 9.0.30 to 9.0.31

[Campbell, Lance]

That was it.  I lost an entire day on that.  I greatly appreciate your time!

Lance

On 4/23/20, 1:30 PM, "Mark Thomas"  wrote:

On 23/04/2020 18:57, Campbell, Lance wrote:
> I am upgrading from Tomcat 9.0.30 to 9.0.31 . This same issue occurs
> with any newer version of Tomcat as well. I have been using Tomcat since
> the earliest version.  I have never had an issue with upgrading or
> installing until now.
> 
> I have a Apache web server with mod_jk and mod_shib.  I have a separate
> tomcat application server.  When I upgraded from 9.0.30 to 9.0.31
> Shibboleth secured tomcat web pages will not work.  Non Shibboleth pages
> work fine.  If I revert tomcat to 9.0.30 it works fine.  I have a
> feeling that there is something new between these two versions that is
> preventing the passing of shibboleth information.
> 
> When I go to a web page that is protected by Shibboleth I get a *HTTP
> Status 403 – Forbidden.*
> 
> In Shibboleth I see no errors.
> 
> Tomcat does not appear to be able to get the page request.
> 
> I see the error in the apache web server log when it tries to send the
> request to the Shibboleth IDP.
> 
> What am I missing?  I would imagine other people have had this issue.

I'm guessing that Shibboleth passes information from httpd to Tomcat via
request attributes. Part of the tightening up of security as a result of
CVE-2020-1938 was restricting the acceptable request attributes.

See allowedRequestAttributesPattern in


http://tomcat.apache.org/tomcat-9.0-doc/config/ajp.html#Standard_Implementations

The quick and dirty test is to set allowedRequestAttributesPattern=".*"
for your AJP connector and see if that fixes it.

If it does, you need to find out what request attributes Shibboleth is
setting and then create a pattern to allow them (the pattern only needs
to match the extra ones, the standard ones are always allowed through).

We don't currently log the problematic attributes. Enabling debug
logging for mod_jk should allow you to figure out the request names if
the Shibboleth documentation doesn't document them.

Mark

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

Strange behavior when deploying new war

[John Larsen]

New tomcats 9.0.34 seems to fail when uploading new war when theres a
context in server.xml pointing to the particular exploded war.  Says 'The
main resource set specified is not valid.' It's like hot deploy is deleting
the old webapp and restarting tomcat?





To work around this one has to comment out the above context, start tomcat
so the war will deploy, uncomment and then restart tomcat again.

John Larsen

Re: Tomcat Upgrade Issue from 9.0.30 to 9.0.31

[Mark Thomas]

On 23/04/2020 18:57, Campbell, Lance wrote:
> I am upgrading from Tomcat 9.0.30 to 9.0.31 . This same issue occurs
> with any newer version of Tomcat as well. I have been using Tomcat since
> the earliest version.  I have never had an issue with upgrading or
> installing until now.
> 
> I have a Apache web server with mod_jk and mod_shib.  I have a separate
> tomcat application server.  When I upgraded from 9.0.30 to 9.0.31
> Shibboleth secured tomcat web pages will not work.  Non Shibboleth pages
> work fine.  If I revert tomcat to 9.0.30 it works fine.  I have a
> feeling that there is something new between these two versions that is
> preventing the passing of shibboleth information.
> 
> When I go to a web page that is protected by Shibboleth I get a *HTTP
> Status 403 – Forbidden.*
> 
> In Shibboleth I see no errors.
> 
> Tomcat does not appear to be able to get the page request.
> 
> I see the error in the apache web server log when it tries to send the
> request to the Shibboleth IDP.
> 
> What am I missing?  I would imagine other people have had this issue.

I'm guessing that Shibboleth passes information from httpd to Tomcat via
request attributes. Part of the tightening up of security as a result of
CVE-2020-1938 was restricting the acceptable request attributes.

See allowedRequestAttributesPattern in

http://tomcat.apache.org/tomcat-9.0-doc/config/ajp.html#Standard_Implementations

The quick and dirty test is to set allowedRequestAttributesPattern=".*"
for your AJP connector and see if that fixes it.

If it does, you need to find out what request attributes Shibboleth is
setting and then create a pattern to allow them (the pattern only needs
to match the extra ones, the standard ones are always allowed through).

We don't currently log the problematic attributes. Enabling debug
logging for mod_jk should allow you to figure out the request names if
the Shibboleth documentation doesn't document them.

Mark

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

Re: 10.0.0-M4 missing PGP signatures?

[Konstantin Kolinko]

чт, 23 апр. 2020 г. в 21:18, Mark Thomas :
>
> On 23/04/2020 18:42, Tianon Gravi wrote:
> > Hi!
> >
> > I'm downloading 10.0.0-M4 from the download page[1] and was hoping to
> > be able to use PGP to verify the artifacts (as in other versions), and
> > it seems the link from that page[2] is a 404?
> >
> > [1]: https://tomcat.apache.org/download-10.cgi
> > [2]: 
> > https://downloads.apache.org/tomcat/tomcat-10/v10.0.0-M4/bin/apache-tomcat-10.0.0-M4.tar.gz.asc
> >
> > I've checked a couple other download mirrors and archive.apache.org,
> > and it appears that M3 *did* include a signature file for
> > "apache-tomcat-10.0.0-M3.tar.gz" (but interestingly, M1 did not
> > include one for "apache-tomcat-10.0.0-M1.tar.gz") so perhaps this is
> > just a pipeline hiccup / minor oversight?
>
> Thanks for the heads up.
>
> That part of the release process is fully automated and it includes
> signature generation.
>
> There have been a couple of glitches lately. I'm not sure what is going
> on. I'll try and watch the console for the next set of builds more
> carefully.
>
> I still have the original build outputs locally so I'll generate any
> missing signatures and get them uploaded.

The *.tar.gz and *.zip files are also published to the Maven
repository (as the org.apache.tomcat:tomcat artifact), and they have
the signatures.

I have a copy of Maven staging repository from the time of release vote.
So I verified that those signatures match the files in the release and
uploaded them to dist.a.o.

Best regards,
Konstantin Kolinko

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

Re: 10.0.0-M4 missing PGP signatures?

[Mark Thomas]

On 23/04/2020 18:42, Tianon Gravi wrote:
> Hi!
> 
> I'm downloading 10.0.0-M4 from the download page[1] and was hoping to
> be able to use PGP to verify the artifacts (as in other versions), and
> it seems the link from that page[2] is a 404?
> 
> [1]: https://tomcat.apache.org/download-10.cgi
> [2]: 
> https://downloads.apache.org/tomcat/tomcat-10/v10.0.0-M4/bin/apache-tomcat-10.0.0-M4.tar.gz.asc
> 
> I've checked a couple other download mirrors and archive.apache.org,
> and it appears that M3 *did* include a signature file for
> "apache-tomcat-10.0.0-M3.tar.gz" (but interestingly, M1 did not
> include one for "apache-tomcat-10.0.0-M1.tar.gz") so perhaps this is
> just a pipeline hiccup / minor oversight?

Thanks for the heads up.

That part of the release process is fully automated and it includes
signature generation.

There have been a couple of glitches lately. I'm not sure what is going
on. I'll try and watch the console for the next set of builds more
carefully.

I still have the original build outputs locally so I'll generate any
missing signatures and get them uploaded.

Mark

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

Tomcat Upgrade Issue from 9.0.30 to 9.0.31

[Campbell, Lance]

I am upgrading from Tomcat 9.0.30 to 9.0.31 . This same issue occurs with any 
newer version of Tomcat as well. I have been using Tomcat since the earliest 
version.  I have never had an issue with upgrading or installing until now.

I have a Apache web server with mod_jk and mod_shib.  I have a separate tomcat 
application server.  When I upgraded from 9.0.30 to 9.0.31 Shibboleth secured 
tomcat web pages will not work.  Non Shibboleth pages work fine.  If I revert 
tomcat to 9.0.30 it works fine.  I have a feeling that there is something new 
between these two versions that is preventing the passing of shibboleth 
information.

When I go to a web page that is protected by Shibboleth I get a HTTP Status 403 
– Forbidden.

In Shibboleth I see no errors.
Tomcat does not appear to be able to get the page request.
I see the error in the apache web server log when it tries to send the request 
to the Shibboleth IDP.

What am I missing?  I would imagine other people have had this issue.

Thanks,

LANCE CAMPBELL
Software Architect

Web Services
Public Affairs
Contact the Webtools Team
217.333.0382
la...@illinois.edu


[/var/folders/wp/1f6l7hw95y718z976kgnl5f9kr5rtc/T/com.microsoft.Outlook/WebArchiveCopyPasteTempFiles/signature_logo.png]

Under the Illinois Freedom of Information Act any written communication to or 
from university employees regarding university business is a public record and 
may be subject to public disclosure.

10.0.0-M4 missing PGP signatures?

[Tianon Gravi]

Hi!

I'm downloading 10.0.0-M4 from the download page[1] and was hoping to
be able to use PGP to verify the artifacts (as in other versions), and
it seems the link from that page[2] is a 404?

[1]: https://tomcat.apache.org/download-10.cgi
[2]: 
https://downloads.apache.org/tomcat/tomcat-10/v10.0.0-M4/bin/apache-tomcat-10.0.0-M4.tar.gz.asc

I've checked a couple other download mirrors and archive.apache.org,
and it appears that M3 *did* include a signature file for
"apache-tomcat-10.0.0-M3.tar.gz" (but interestingly, M1 did not
include one for "apache-tomcat-10.0.0-M1.tar.gz") so perhaps this is
just a pipeline hiccup / minor oversight?

Thanks for your work on Tomcat!

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

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

Re: Illegal reflective access by org.apache.catalina.loader.WebappClassLoaderBase

[Mark Thomas]

On 23/04/2020 10:49, Hua Zhang wrote:
> Best Tomcat maintainers,
> 
> I would like to report the following warning message.
> 
> When redeploy a web application, there will be a warning message like this:

Yes we know. It is intentional.

Mark


> *WARNING: An illegal reflective access operation has occurredWARNING:
> Illegal reflective access by
> org.apache.catalina.loader.WebappClassLoaderBase to field
> java.io.ObjectStreamClass$Caches.localDescsWARNING: Please consider
> reporting this to the maintainers of
> org.apache.catalina.loader.WebappClassLoaderBaseWARNING: Use
> --illegal-access=warn to enable warnings of further illegal reflective
> access operationsWARNING: All illegal access operations will be denied in a
> future release*
> 
> I have already debugged it and find the message happens only *java 11*.
> 
> In WebappClassLoaderBase class: clearReferencesObjectStreamClassCaches()
> -> clearCache(clazz, "localDescs") -> f.setAccessible(true);
> 
> in java 11, The f (java.lang.reflect.Field) setAccessible overrides its
> superclass, which contains the following check:
> if (flag) checkCanSetAccessible(Reflection.getCallerClass());
> 
> And this check results the above warning messages.
> 
> 
> Best regards,
> 
> Hua
> 


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

Illegal reflective access by org.apache.catalina.loader.WebappClassLoaderBase

[Hua Zhang]

Best Tomcat maintainers,

I would like to report the following warning message.

When redeploy a web application, there will be a warning message like this:






*WARNING: An illegal reflective access operation has occurredWARNING:
Illegal reflective access by
org.apache.catalina.loader.WebappClassLoaderBase to field
java.io.ObjectStreamClass$Caches.localDescsWARNING: Please consider
reporting this to the maintainers of
org.apache.catalina.loader.WebappClassLoaderBaseWARNING: Use
--illegal-access=warn to enable warnings of further illegal reflective
access operationsWARNING: All illegal access operations will be denied in a
future release*

I have already debugged it and find the message happens only *java 11*.

In WebappClassLoaderBase class: clearReferencesObjectStreamClassCaches()
-> clearCache(clazz, "localDescs") -> f.setAccessible(true);

in java 11, The f (java.lang.reflect.Field) setAccessible overrides its
superclass, which contains the following check:
if (flag) checkCanSetAccessible(Reflection.getCallerClass());

And this check results the above warning messages.


Best regards,

Hua