The tomcat is not running in any containers.
We don’t have anything Linux cron.
The containerbackgroundprocessor which I mentioned is within the tomcat.
The tomcat’s Catalina.out file printing that name when doing the app
undeploy and deploy on Saturday.
On Fri, Oct 15, 2021 at 11:17 AM Darryl Ph
Chris,
really appreciate you taking some time to respond. See my replies inline below.
> -Original Message-
> From: Christopher Schultz
> Sent: Thursday, October 14, 2021 12:19 PM
> To: users@tomcat.apache.org
> Subject: Re: Tomcat 9.0.x JDBC connection pool does not always remove
> aba
Werner,
On 10/15/21 09:10, Werner Dähn wrote:
Thanks Mark. Why do you believe the refactoring is difficult? All we
actually need is access to the response object.
... which requires a lot of refactoring. Have a look at all the code
that handles authentication in Tomcat.
This would allow to
On 10/15/21, 10:05 AM, "jonmcalexan...@wellsfargo.com.INVALID"
wrote:
> -Original Message-
> From: Shekhar Naidu
> Sent: Friday, October 15, 2021 7:45 AM
> To: users@tomcat.apache.org
> Subject: Tomcat 8.5.37 is automatically redeploying apps on every Saturday
>
> -Original Message-
> From: Shekhar Naidu
> Sent: Friday, October 15, 2021 7:45 AM
> To: users@tomcat.apache.org
> Subject: Tomcat 8.5.37 is automatically redeploying apps on every Saturday
>
> Hi all,
>
> > We are seeing a weird behavior in our new Linux environments. Since we
> >> mig
Thanks Mark. Why do you believe the refactoring is difficult? All we
actually need is access to the response object. This would allow to add
session data, URL parameters, whatever. And this response object is
available everywhere except in the actual RealmBase. By my analysis the
change would be ra
Hi all,
> We are seeing a weird behavior in our new Linux environments. Since we
>> migrated from RHEL6 to 8, we started seeing issue with tomcat. Tomcat is
>> auto redeploying our apps on every Saturday around 12:20AM.
>> We don’t have any schedulers running on our machines. We verified
>> localh
On 15/10/2021 07:05, Werner Dähn wrote:
So why has this not been done? What am I missing?
Accepted security good practice is not to provide any information to a
user as to the reason for a failed authentication. The idea is that it
could help an attacker by, for example, letting them know
