from:"christopher"

John,

On 9/30/24 13:34, John Williams wrote:

No - I cannot see any other thread stuck on DB/external resources. The 
application functions as expected, just that I see these threads increasing 
over time.
The problem was 1st noticed in Tomcat 10.1.26/OpenJRE 17.0.5 and I've tried 
moving to Tomcat 10.1.30/OpenJRE 17.0.12 with no change.

If you go back to 10.0 does it still behave as expected?

You have a bit of a weird setup IMHO.

>   maxThreads="1536"

This is a very strange number. Why not 1537?

>   minSpareThreads="64"

This seems reasonable, but also kind of low given:

  acceptCount="12000"

So you are willing to accept HUGE numbers of connections and then let 
them sit in the TCP/IP stack's accept queue waiting for a processing 
thread. Why?

  connectionTimeout="6"

Ouch. So you will accept huge numbers of connections and then allow them 
to sit there not making any request? This seems like a recipe for disaster.

  socket.rxBufSize="131072"

>   socket.txBufSize="131072"

Tweaking the socket buffer sizes is either an indication of an insanely 
well-tuned performance setup or that you don't know what you are doing. 
Given the other settings, I'm inclined toward the latter.

>   maxKeepAliveRequests="1"

Disabling pipelining? Definitely not expecting a high performance 
service, or you are very sure that no client will ever make more than 
one request.

>  maxConnections="1536"

You don't want this, especially for NIO. There is no reason to reduce 
this from the default, although your other settings make the 
non-blocking nature of the NIO connector moot (e.g. pipelining is disabled).

Why do you have this collection of odd settings?

-chris

-Original Message-
From: Chuck Caldarale 
Sent: Monday, September 30, 2024 1:26 PM
To: Tomcat Users List 
Subject: Re: Tomcat 10.1.30 and Many Timed Waiting threads

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

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

On Sep 30, 2024, at 12:15, John Williams 
 wrote:

I had an executor defined before and it had the exact same behavior/problem. 
Moved to the below model for the connector only after that.

The OP didn't mention the real problem in his original message; it only showed 
up as almost an afterthought in the second posting with the unusable 
attachments:

"Once it reaches close to the maxThreads setting we see connection drops."

I wonder if there's something else blocking the application, such as stuck DB 
operations or other delayed access to an external resource.

   - Chuck

-
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: [OT] accessing manager app


Michael,

On 9/30/24 11:41, Michael Osipov wrote:

Chris,

On 2024/09/30 14:33:53 Christopher Schultz wrote:

Michael,

On 9/28/24 13:34, Michael Osipov wrote:

On 2024/09/27 15:14:15 Christopher Schultz wrote:

Sebastian,

On 9/27/24 11:04, Sebastian Trost wrote:

Francesco,

On 26.09.2024 16:12, Francesco Viscomi wrote:

Hi all,
I'm not able to understand why I cannot access to
    http://localhost:8080/manager/html

I've configured the user in tomcat.users.xml:




I'm using tomcat 9; and jdk17;

I've also noted that in my personal pc when try to access manager/html a
pop up ask me to login (in my personal pc it works right)

While when I try to use it in the company pc it gives me 401
unauthorized;
I do not know what I have to modify on chrome to get access in manager
app,
I also use in the company pc Zscaler, but I do not know what I have to
change in it (eventually) in order to access the manager app.

Your corporate browser probably has basic authentication disabled. Check
this site: https://jigsaw.w3.org/HTTP/Basic
If there is no basic authentication popup where you can enter username/
password then this is probably the case.

See: https://answers.microsoft.com/en-us/microsoftedge/forum/all/latest-
version-of-edge-no-longer-shows-basic/3601252b-e56b-46c0-a088-0f6084eabe47


I've really had it with Microsoft deciding that HTTP Basic
authentication is just not okay. They seem to have forgotten that TLS
makes it secure.


The reasoning is never to share a long term secret: your password.


HTTP Digest also requires pre-shared passwords.


There is a subtile difference: the password is never transferred over the wire 
and does not appear on the target server.


While that may be true, it is irrelevant. The 
MD5(username:reaml:password) must be known to the server. That is as 
good as the password in terms of security.


The realm name can never be changed without changing all passwords. The 
algorithm used can never be changed without changing all passwords.


The overwhelming majority of web-based applications use pre-shared 
passwords with FORM-based authentication over TLS. There is zero 
reduction in security when compared to HTTP Digest. In both cases, 
hashes can be stored on the server-side which is of course a best-practice.



HTTP Digest is a nightmare, but they are forcing users onto it.


The key is to use SPNEGO in enterprise environments.


What about non-enterprise environments?


IMHO, this is irrelevant for Microsoft. In enterprise you do have at least 
SPNEGO or even PKI. For non-enterprise I see only Basic as a viable option.


Except that Microsoft is killing it.

At $work, we use WebDAV over TLS with an OpenLDAP back-end for 
authentication. It works great for all employees except those who use 
Windows. It seems like every installation of Windows needs a different 
hack to get HTTP Basic working when connecting to WebDAV.


There is no "Enterprise" here. There are no Domain Controllers here. 
There is no expensive third-party authentication-as-a-service company 
here. There is only a standards-compliant service which is not reliably 
accessible to users on Microsoft Windows.


And it annoys the hell out of me.

-chris


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

Re: Tomcat 10.1.30 and Many Timed Waiting threads

John,

On 9/30/24 10:53, John Williams wrote:

Sorry - didn't realize that images would be stripped off.

The number of TIMED_WAITING threads starts at 150 or so and every hour 
increases by 10.

Below is an example of where the threads are stuck (by looking at the JVM 
stack):

https-jsse-nio2-443-exec-90
TIMED_WAITING on 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@48986fd7
jdk.internal.misc.Unsafe.park(Native Method);
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:252);
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:1674);
java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:460);
app//org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:99);
app//org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:33);
app//org.apache.tomcat.util.threads.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1113);
app//org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1175);
app//org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659);
app//org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:63);
java.base@17.0.12/java.lang.Thread.run(Thread.java:840);

The connector configuration is:

You are not explicitly using an . When you configure using 
 only, Tomcat will never retire the threads from the 
thread-pool. This is mostly historic and while it could be improved, it 
is better to switch to a mode modern configuration.

If you use  and:

Then you should see the number of threads fluxuate based upon the 
request volume.

I'm not sure why you were seeing different behavior with Tomcat 10.0. 
IIRC this behavior has been consistent as long as  and 
 have been separate configuration elements.

-chris

-Original Message-----
From: Christopher Schultz 
Sent: Monday, September 30, 2024 10:38 AM
To: users@tomcat.apache.org
Subject: Re: Tomcat 10.1.30 and Many Timed Waiting threads

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

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

John,

On 9/30/24 10:30, John Williams wrote:

The issue is that the number of threads in the TIMED_WAIT state keeps
increasing over time. Starts at 150 and keeps growing by 10 every hour.
Once it reaches close to the maxThreads setting we see connection drops.

This application was working fine with Tomcat 10.0 and JDK 12. Unless
the application was seeing load, threads would not be created in
Tomcat's JVM.

You can also see the thread stacks in this image.

This list strips out image. Can you post text?

Please post your  configuration taking care to remove any secrets.

Thanks,
-chris

-Original Message-----
From: Christopher Schultz 
Sent: Monday, September 30, 2024 10:20 AM
To: users@tomcat.apache.org
Subject: Re: Tomcat 10.1.30 and Many Timed Waiting threads

[You don't often get email from ch...@christopherschultz.net
<mailto:ch...@christopherschultz.net>. Learn why this is important at
https://aka.ms/LearnAboutSenderIdentification
<https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka
.ms%2F&data=05%7C02%7Csrinivas%40eginnovations.com%7C5c93ec3de0884e786
7d708dce15d7e73%7C62c210cb17214d259b6b0c95ceb472ce%7C0%7C0%7C638633038
912339442%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=6q8HQHLjceSHYLqEnLN9
ue%2Fpa3zz5cougsajpZIsjDw%3D&reserved=0
LearnAboutSenderIdentification> ]

CAUTION: This email originated from outside of the organization. Do
not click links or open attachments unless you recognize the sender
and know the content is safe.

John,

On 9/28/24 05:38, John Williams wrote:

  >

  > Hi Everyone,

  >

  > I am running Apache Tomcat 10.1.30 for a web application and notice
~950 timed_waiting threads.

  >

  > The stack trace for these threads is below:

  >

  > java.base@17.0.12/
jdk.internal.misc.Unsafe.park(Native<mailto:java.bas
<mailto:java.base@17.0.12/
jdk.internal.misc.Unsafe.park(Native%3cmailto:java.bas>

  > e@17.0.12/jdk.internal.misc.Unsafe.park(Native <mailto:e@17.0.12/
jdk.internal.misc.Unsafe.park(Native>> Method);

  > java.base@17.0.12/
java.util.concurrent.locks.LockSupport.parkNanos(Loc
<mailto:java.base@17.0.12/
java.util.concurrent.locks.LockSupport.parkNanos(Loc>

  >
kSupport.java:252)<mailto:java.base@17.0.12/java.util.concurrent.locks

  > .LockSupport.parkNanos(LockSupport.java:252)>;

  > java.base@17.0.12/
java.util.concurrent.locks.AbstractQueuedSynchronize
<mailto:java.base@17.0.12/
java.util.concurrent.locks

Re: Tomcat 10.1.30 and Many Timed Waiting threads


John,

On 9/30/24 10:30, John Williams wrote:
The issue is that the number of threads in the TIMED_WAIT state keeps 
increasing over time. Starts at 150 and keeps growing by 10 every hour. 
Once it reaches close to the maxThreads setting we see connection drops.


This application was working fine with Tomcat 10.0 and JDK 12. Unless 
the application was seeing load, threads would not be created in 
Tomcat’s JVM.


You can also see the thread stacks in this image.


This list strips out image. Can you post text?

Please post your  configuration taking care to remove any 
secrets.


Thanks,
-chris


-Original Message-
From: Christopher Schultz 
Sent: Monday, September 30, 2024 10:20 AM
To: users@tomcat.apache.org
Subject: Re: Tomcat 10.1.30 and Many Timed Waiting threads

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


CAUTION: This email originated from outside of the organization. Do not 
click links or open attachments unless you recognize the sender and know 
the content is safe.


John,

On 9/28/24 05:38, John Williams wrote:

 >

 > Hi Everyone,

 >

 > I am running Apache Tomcat 10.1.30 for a web application and notice 
~950 timed_waiting threads.


 >

 > The stack trace for these threads is below:

 >

 > java.base@17.0.12/ 
jdk.internal.misc.Unsafe.park(Native<mailto:java.bas 
<mailto:java.base@17.0.12/ 
jdk.internal.misc.Unsafe.park(Native%3cmailto:java.bas>


 > e@17.0.12/jdk.internal.misc.Unsafe.park(Native <mailto:e@17.0.12/ 
jdk.internal.misc.Unsafe.park(Native>> Method);


 > java.base@17.0.12/ 
java.util.concurrent.locks.LockSupport.parkNanos(Loc 
<mailto:java.base@17.0.12/ 
java.util.concurrent.locks.LockSupport.parkNanos(Loc>


 > kSupport.java:252)<mailto:java.base@17.0.12/java.util.concurrent.locks

 > .LockSupport.parkNanos(LockSupport.java:252)>;

 > java.base@17.0.12/ 
java.util.concurrent.locks.AbstractQueuedSynchronize 
<mailto:java.base@17.0.12/ 
java.util.concurrent.locks.AbstractQueuedSynchronize>


 > r$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:1674) lto:java.base@17.0.12/java.util.concurrent.locks.AbstractQueuedSynchro

 > nizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:1674)

 > >;

 > java.base@17.0.12/ 
java.util.concurrent.LinkedBlockingQueue.poll(Linked 
<mailto:java.base@17.0.12/ 
java.util.concurrent.LinkedBlockingQueue.poll(Linked>


 > BlockingQueue.java:460)<mailto:java.base@17.0.12/java.util.concurrent.

 > LinkedBlockingQueue.poll(LinkedBlockingQueue.java:460)>;

 > app//org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:99);

 > app//org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:33);

 > app//org.apache.tomcat.util.threads.ThreadPoolExecutor.getTask(ThreadP

 > oolExecutor.java:1113);

 > app//org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(Threa

 > dPoolExecutor.java:1175);

 > app//org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(Thre

 > adPoolExecutor.java:659);

 > app//org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(Ta

 > skThread.java:63);

 > java.base@17.0.12/ 
java.lang.Thread.run(Thread.java:840)<mailto:java.ba 
<mailto:java.base@17.0.12/ 
java.lang.Thread.run(Thread.java:840)%3cmailto:java.ba>


 > se@17.0.12/java.lang.Thread.run(Thread.java:840) <mailto:se@17.0.12/ 
java.lang.Thread.run(Thread.java:840)>>;


 >

 > I am using an executor with maxThreads set to 1500 and 
minSpareThreads set to 64.


 >

 > I have not seen this issue with Tomcat 10.0.

 >

 > What could be the issue and how to resolve it? Any help is much 
appreciated.


This looks like you have a large number of threads waiting for work.

That seems normal to me if you have a max thread pool of 1500 threads.

What's the problem?

-chris

-

To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org 
<mailto:users-unsubscr...@tomcat.apache.org>


For additional commands, e-mail: users-h...@tomcat.apache.org 
<mailto: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: accessing manager app


Michael,

On 9/28/24 13:34, Michael Osipov wrote:

On 2024/09/27 15:14:15 Christopher Schultz wrote:

Sebastian,

On 9/27/24 11:04, Sebastian Trost wrote:

Francesco,

On 26.09.2024 16:12, Francesco Viscomi wrote:

Hi all,
I'm not able to understand why I cannot access to
   http://localhost:8080/manager/html

I've configured the user in tomcat.users.xml:




I'm using tomcat 9; and jdk17;

I've also noted that in my personal pc when try to access manager/html a
pop up ask me to login (in my personal pc it works right)

While when I try to use it in the company pc it gives me 401
unauthorized;
I do not know what I have to modify on chrome to get access in manager
app,
I also use in the company pc Zscaler, but I do not know what I have to
change in it (eventually) in order to access the manager app.

Your corporate browser probably has basic authentication disabled. Check
this site: https://jigsaw.w3.org/HTTP/Basic
If there is no basic authentication popup where you can enter username/
password then this is probably the case.

See: https://answers.microsoft.com/en-us/microsoftedge/forum/all/latest-
version-of-edge-no-longer-shows-basic/3601252b-e56b-46c0-a088-0f6084eabe47


I've really had it with Microsoft deciding that HTTP Basic
authentication is just not okay. They seem to have forgotten that TLS
makes it secure.


The reasoning is never to share a long term secret: your password.


HTTP Digest also requires pre-shared passwords.


HTTP Digest is a nightmare, but they are forcing users onto it.


The key is to use SPNEGO in enterprise environments.


What about non-enterprise environments?

-chris


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

Re: Tomcat 10.1.30 and Many Timed Waiting threads


John,

On 9/28/24 05:38, John Williams wrote:


Hi Everyone,

I am running Apache Tomcat 10.1.30 for a web application and notice ~950 
timed_waiting threads.

The stack trace for these threads is below:

java.base@17.0.12/jdk.internal.misc.Unsafe.park(Native
 Method);
java.base@17.0.12/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:252);
java.base@17.0.12/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:1674);
java.base@17.0.12/java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:460);
app//org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:99);
app//org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:33);
app//org.apache.tomcat.util.threads.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1113);
app//org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1175);
app//org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659);
app//org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:63);
java.base@17.0.12/java.lang.Thread.run(Thread.java:840);

I am using an executor with maxThreads set to 1500 and minSpareThreads set to 
64.

I have not seen this issue with Tomcat 10.0.

What could be the issue and how to resolve it? Any help is much appreciated.


This looks like you have a large number of threads waiting for work. 
That seems normal to me if you have a max thread pool of 1500 threads.


What's the problem?

-chris


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

Re: accessing manager app


Sebastian,

On 9/27/24 11:04, Sebastian Trost wrote:

Francesco,

On 26.09.2024 16:12, Francesco Viscomi wrote:

Hi all,
I'm not able to understand why I cannot access to
  http://localhost:8080/manager/html

I've configured the user in tomcat.users.xml:




I'm using tomcat 9; and jdk17;

I've also noted that in my personal pc when try to access manager/html a
pop up ask me to login (in my personal pc it works right)

While when I try to use it in the company pc it gives me 401 
unauthorized;
I do not know what I have to modify on chrome to get access in manager 
app,

I also use in the company pc Zscaler, but I do not know what I have to
change in it (eventually) in order to access the manager app.
Your corporate browser probably has basic authentication disabled. Check 
this site: https://jigsaw.w3.org/HTTP/Basic
If there is no basic authentication popup where you can enter username/ 
password then this is probably the case.


See: https://answers.microsoft.com/en-us/microsoftedge/forum/all/latest- 
version-of-edge-no-longer-shows-basic/3601252b-e56b-46c0-a088-0f6084eabe47


I've really had it with Microsoft deciding that HTTP Basic 
authentication is just not okay. They seem to have forgotten that TLS 
makes it secure.


HTTP Digest is a nightmare, but they are forcing users onto it.

-chris


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

Re: Website inconsistency


Mark,

On 9/26/24 11:18, Mark Thomas wrote:

On 26/09/2024 16:05, Doug Whitfield wrote:

Hi Folks,

On the left sidebar of the website the download is for “Tomcat 10” 
while the Documentation is for “Tomcat 10.1”. Now, between Download 
and Documentation things are consistent.


I don’t think this is strictly speaking wrong, but I don’t see any 
good reason for it and I do think it is a bit confusing. Is there a 
good reason that I am missing?


The download links refer to just the major version. The docs refer to 
the major and minor.


The reason is that sometimes (eg 10.0.x and 10.1.x) we have multiple 
minors of the same major being released at the same time. The download 
pages are per major but the docs are the latest release of each minor.


It looks slightly odd at the moment now you mention it but not enough 
I'm motivated to go and fix it.


It does look slightly odd and wouldn't be a big deal to change, I think.

When we still supported Tomcat 8.5, the download links said "Tomcat 8" 
and the documentation links said "Tomcat 8.5". At least then it looked 
intentional. At this point, only Tomcat 10.1 looks out of place.



Do we want a single download page for all Tomcat versions?


I think our download pages are sufficiently verbose that we'd really 
want to think about that. Also, the release process for each separate 
branch is configured to update individual pages. Merging them would take 
some doing, and I think we'd want to re-design the page to make it 
easier to find what you are looking for quickly.


-chris


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

Re: Mitigate CVE-2024-34750 by removing UpgradeProtocol...Http2Protocol ?


Tom,

On 9/27/24 10:49, Tom Colley wrote:
In releases prior to 10.1.25, Can CVS-2024-34750 (https://nvd.nist.gov/ 
vuln/detail/CVE-2024-34750 ) be mitigated by removing className="org.apache.coyote.http2.Http2Protocol" /> (which I'm thinking 
would disable HTTP/2) from all of the connectors in server.xml?


Yes, disabling h2 will mitigate all h2-related vulnerabilities.

-chris


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

Re: tomcat startup error, IBM DB2 related (database) [SPAM]


Shekhar,

On 9/24/24 04:51, Shekhar Dhotre wrote:

Contact Neel at neel.dho...@contractor.tatacommunications.com  , He
recently restored our important financial app which is running same
setup. Tomcat, Db2 , IBM ldap, Redhat, oracle, etc. There is a
endorsement  on the same at LinkedIn.

Please don't post service advertisements to this list.

-chris


-Original Message-
From: Michael Lau 
Sent: 24 September 2024 13:28
To: users@tomcat.apache.org
Cc: reggie.v.gokot...@accenture.com; neil.james.perdi...@accenture.com
Subject: tomcat startup error, IBM DB2 related (database)

Good afternoon,

we've been having trouble trying to start-up our server for a while, tried 
restarting again and again and error still persists we can't run our website. 
It's been ok for the past few weeks it's just we failed to shut down the server 
properly and may have messed things up with residue processes/threads that 
wasn't closed (my friend just clicked the x button on the cmd window of the 
server running). Trying to find solutions to get the server up and running 
again. I downloaded the driver pack for IBM DB2 and may try to put it in the 
lib folder of apache, or install the entire software (1.3GB) from the IBM 
download I got too. not sure if it's the .jar file that's the problem, but the 
error does indicate the .properties file of db2 configuration. not sure if this 
should be auto-generated in the web app or it's just plain missing. My 
colleague suggested to revert to the default settings of apache but this would 
create problems with the web app since I think it uses db2 by default as it's 
database, plus I'm kind of new to tomcat so I don't know which xml file to pick 
to set the database or library/software used. Would like to get this resolved 
as it's a minor roadblock to finishing our task. currently I think it's just a 
.jar library problem or just a configuration problem, could also be an improper 
shutdown problem. I can't access apache manager to see if the program really 
shutdown entirely since we can't run the server.. I read there might be a 
detailed log of the error.

here's a clip of the error from the cmd window of my friend:

0-Sep-2024 13:51:51.584 INFO [Timer-0]
org.apache.catalina.loader.WebappClassLoaderBase.checkStateForResourceLoading
Illegal access: this web application instance has been stopped already.
Could not load [com/ibm/db2/jcc/DB2JccConfiguration.properties]. The following 
stack trace is thrown for debugging purposes as well as to attempt to terminate 
the thread which caused the illegal access.

 java.lang.IllegalStateException: Illegal access: this web application 
instance has been stopped already. Could not load 
[com/ibm/db2/jcc/DB2JccConfiguration.properties]. The following stack trace is 
thrown for debugging purposes as well as to attempt to terminate the thread 
which caused the illegal access.

 at
org.apache.catalina.loader.WebappClassLoaderBase.checkStateForResourceLoading(WebappClassLoaderBase.java:1384)

 at
org.apache.catalina.loader.WebappClassLoaderBase.getResource(WebappClassLoaderBase.java:1034)

 at com.ibm.db2.jcc.am.vd.run(vd.java:70)

 at java.security.AccessController.doPrivileged(Native
Method)

 at
com.ibm.db2.jcc.am.GlobalProperties.a(GlobalProperties.java:152)

 at
com.ibm.db2.jcc.am.GlobalProperties.d(GlobalProperties.java:100)

 at com.ibm.db2.jcc.am.ar.run(ar.java:124)

 at java.util.TimerThread.mainLoop(Timer.java:555)

 at java.util.TimerThread.run(Timer.java:505)


THANK YOU


best regards,

Mike

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

Re: tomcat query

2024-09-23 Thread Christopher Schultz


Mark,

On 9/23/24 08:58, Mark Thomas wrote:

On 23/09/2024 13:50, Rachana Kharchane wrote:

Hi Team,

I Have few queries

How can we ensure the old  config is kept in place post installing a 
new tomcat version?


Do we have options to backup the configuration and reapply after new 
version install of Tomcat?


Read RUNNING.txt in the root of your Tomcat distribution.


Also, https://tomcat.apache.org/upgrading.html

-chris

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

Re: Tomcat doesn't allow me to login

2024-09-23 Thread Christopher Schultz


Please don't hikack threads.

Also, don't run as root.

On 9/20/24 16:54, Shekhar Dhotre wrote:

[root@mtthdoped51 ~]# $CATALINA_HOME/bin/startup.sh

Using CATALINA_BASE:   /opt/tomcat/latest

Using CATALINA_HOME:   /opt/tomcat/latest

Using CATALINA_TMPDIR: /opt/tomcat/latest/temp

Using JRE_HOME:    /usr/lib/jvm/java-11-openjdk-11.0.24.0.8-2.el9.x86_64

Using CLASSPATH:   /opt/tomcat/latest/bin/bootstrap.jar:/opt/tomcat/ 
latest/bin/tomcat-juli.jar


Using CATALINA_OPTS:

Tomcat started.

[

I even took out below from users.xml

http://tomcat.apache.org/xml tomcat.apache.org/xml>


   xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance 



   xsi:schemaLocation=http://tomcat.apache.org/xml tomcat- 
users.xsd 


   version="1.0">

     

     

     

     




Tried all commands

   159  vi /opt/tomcat/apache-tomcat-10.1.30/conf/tomcat-users.xml

   160  $CATALINA_HOME/bin/shutdown.sh

   161  $CATALINA_HOME/bin/startup.sh

   162  vi /opt/tomcat/apache-tomcat-10.1.30/conf/tomcat-users.xml

   163  vi /opt/tomcat/apache-tomcat-10.1.30/conf/server.xml

   164  keytool -genkey -alias tomcat -keyalg RSA -keystore conf/ 
localhost-rsa.jks


   165  vi /opt/tomcat/apache-tomcat-10.1.30/conf/tomcat-users.xml

   166  keytool -genkey -alias tomcat -keyalg RSA -keystore /opt/tomcat/ 
apache-tomcat-10.1.30/conf/localhost-rsa.jks


   167  find / -name server.xml -print

   168  vi /opt/config/instance1/conf/server.xml

   169  $CATALINA_HOME/bin/shutdown.sh

   170  $CATALINA_HOME/bin/startup.sh

   171  vi /opt/config/instance1/conf/server.xml

   172  $CATALINA_HOME/bin/shutdown.sh

   173  $CATALINA_HOME/bin/startup.sh

   174  cat  /opt/config/instance1/conf/server.xml

   175  vi /opt/config/instance1/conf/server.xml

   176  ls -l /opt/tomcat/apache-tomcat-10.1.30/conf/localhost-rsa.jks

   177  vi /opt/tomcat/apache-tomcat-10.1.30/conf/tomcat-users.xml

   178  $CATALINA_HOME/bin/shutdown.sh

   179  $CATALINA_HOME/bin/startup.sh

   180  cat  /opt/tomcat/apache-tomcat-10.1.30/conf/tomcat-users.xml

   181  export CATALINA_BASE=/opt/tomcat/apache-tomcat-10.1.30

   182  cat  /opt/tomcat/apache-tomcat-10.1.30/conf/tomcat-users.xml

   183  vi /opt/tomcat/apache-tomcat-10.1.30/conf/tomcat-users.xml

   184  $CATALINA_HOME/bin/shutdown.sh

   185  $CATALINA_HOME/bin/startup.sh

   186  tail -f $CATALINA_BASE/logs/catalina.out

   187  find / -name tomcat-users.xml

   188  vi /opt/config/instance1/conf/tomcat-users.xml

   189  $CATALINA_HOME/bin/shutdown.sh

   190  $CATALINA_HOME/bin/startup.sh

   191  /opt/tomcat/apache-tomcat-10.1.30/webapps/host-manager/META-INF/ 
context.xml


   192  vi /opt/tomcat/apache-tomcat-10.1.30/webapps/host-manager/META- 
INF/context.xml


   193  $CATALINA_HOME/bin/shutdown.sh

   194  $CATALINA_HOME/bin/startup.sh

   195  tail -f $CATALINA_BASE/logs/catalina.out

   196  find / -name tomcat-users.xml

   197  vi /opt/tomcat/apache-tomcat-10.1.30/conf/tomcat-users.xml

   198  $CATALINA_HOME/bin/shutdown.sh

   199  $CATALINA_HOME/bin/startup.sh

   200  find / -name tomcat-users.xml

   201  vi /opt/config/instance1/conf/tomcat-users.xml

   202  $CATALINA_HOME/bin/shutdown.sh

   203  $CATALINA_HOME/bin/startup.sh

   204  vi /opt/config/instance1/conf/tomcat-users.xml

   205  vi /opt/tomcat/apache-tomcat-10.1.30/conf/tomcat-users.xml

   206  $CATALINA_HOME/bin/shutdown.sh

   207  $CATALINA_HOME/bin/startup.sh

   208  reboot

   209  tail -f $CATALINA_BASE/logs/catalina.out

   210  $CATALINA_HOME/bin/startup.sh

   211  tail -f $CATALINA_BASE/logs/catalina.out

   212  history




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

Re: Error migrating to Tomcat 10.1

2024-09-20 Thread Christopher Schultz


Lance,

On 9/20/24 09:23, Campbell, Lance wrote:

I was wrong. I did confirm what code was causing the issue. In my servlet at 
the top I did this:

cookie[index].setMaxAge(0);
resp.addCookie(cookie[index]);

Then at the bottom of the code I did:

resp.sendRedirect(".");

When I commented out the code relating to the cookies it then worked.  I 
believe that if you call resp.sendRedirect you may not be able to do anything 
else with the resp. This is just a guess.


You might be able to do things with the response *if* the response has 
not been "committed". A response is "committed" when the first bytes -- 
usually the full set of headers and possibly some of the response body 
-- have actually been sent to the network interface.


Once that happens, the only thing you can really do is destroy the 
response body and show the user an ugly page.


None of this stuff is related to your original report of AJP errors. 
Check the max_packet_size on httpd and the packetSize in Tomcat, as Mark 
suggested.


We recently upgraded from Tomcat 8 -> Tomcat 9 in production and we were 
surprised to find similar errors in spite of configurations that should 
have been identical to our previous version. A re-sync of the packet 
size configuration got everything working perfectly again.


-chris


-Original Message-
From: Mark Thomas 
Sent: Friday, September 20, 2024 1:23 AM
To: users@tomcat.apache.org
Subject: Re: Error migrating to Tomcat 10.1

On 19/09/2024 21:16, Campbell, Lance wrote:

I think I might have found the issue.  I built my web app with Java 8 and 
Tomcat 9 using version 4.0 of the web-app species originally.  This was a 
servlet mapping I had:


  NavigationServlet
  *.navigation


Notice the url-pattern. It has *.navigation.

Now I am using Java 17 and Tomcat 10.1 with version 5.0 of the web-app specs.  
Is the above allowed with a URL redirection?


Yes.



  I think the *.xyz might be the issue with HttpServletResponse sendRedirect .

  > > Thoughts?

Unlikely related given the error you are seeing.

Mark




Thanks


-Original Message-
From: Mark Thomas 
Sent: Thursday, September 19, 2024 2:52 PM
To: users@tomcat.apache.org
Subject: Re: Error migrating to Tomcat 10.1

On 19/09/2024 20:19, Campbell, Lance wrote:

I am using the latest Tomcat 10.1

Java 17

Apache Web server communicates with an application server running tomcat.  The 
application name is webtools.

I am migrating a working app from Tomcat 9 to Tomcat 10.1.


Does your AJP connector in Tomcat 9 have a packetSize attribute? If
yes, you need to copy that across to 10.1

You can also check your work configuration on httpd for max_packet_size.
The two values have to agree.

Mark




I am getting this error in the tomcat app after sending a web request. It seems 
like it is starting to load things. Then I see the below:

19-Sep-2024 13:54:54.086 INFO [main]
org.apache.catalina.startup.HostConfig.deployDescriptor Deployment of
deployment descriptor
[/../webtools/conf/Catalina/localhost/ROOT.xml] has finished in
[3,782] ms
19-Sep-2024 13:54:54.089 INFO [main]
org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler
["ajp-nio-0:0:0:0:0:0:0:0-8149"]
19-Sep-2024 13:54:54.101 INFO [main]
org.apache.catalina.startup.Catalina.start Server startup in [3873]
milliseconds
19-Sep-2024 13:54:55.332 SEVERE [ajp-nio-0:0:0:0:0:0:0:0-8149-exec-1] 
org.apache.coyote.ajp.AjpMessage.checkOverflow Overflow error for buffer adding 
[113] bytes at position [8085]
   java.lang.ArrayIndexOutOfBoundsException
   at 
org.apache.coyote.ajp.AjpMessage.checkOverflow(AjpMessage.java:242)
   at 
org.apache.coyote.ajp.AjpMessage.appendBytes(AjpMessage.java:211)
   at 
org.apache.coyote.ajp.AjpMessage.appendByteChunk(AjpMessage.java:197)
   at 
org.apache.coyote.ajp.AjpMessage.appendBytes(AjpMessage.java:181)
   at 
org.apache.coyote.ajp.AjpProcessor.prepareResponse(AjpProcessor.java:991)
   at 
org.apache.coyote.AbstractProcessor.action(AbstractProcessor.java:377)
   at org.apache.coyote.Response.action(Response.java:210)
   at org.apache.coyote.Response.commit(Response.java:464)
   at 
org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:285)
   at 
org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:244)
   at 
org.apache.catalina.connector.Response.finishResponse(Response.java:421)
   at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:373)
   at 
org.apache.coyote.ajp.AjpProcessor.service(AjpProcessor.java:431)
   at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:63)
   at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:904)
   at 
org.apache.tomca

Re: Trying to Resolve a Java Version Vulnerability I'm Using for Tomcat

2024-09-11 Thread Christopher Schultz


Michael,

On 9/11/24 09:13, Ferrick, Michael wrote:

Hello,

The powers above have notified me that the Java version 9.0.1.0 (x64) that I am 
using with Apache Tomcat 9.0.84 has a vulnerability on my Windows servers (OS 
2019) and MUST be remediated. That means use another Java version!

I removed Java 9.0.1 (64-bit) and Java (tm) SE Development Kit 9.0 (64-bit) 
from the Control Panel (It notified me that it would stop Tomcat) and I 
installed jdk-8u421-windows-x64.exe in the default location of C:Program 
Files\Java, which was the same location as the original 9.0.1.0 version.

Apache Software is located on E:\Program Files\Apache Software 
Foundation\Tomcat 9.0.

I opened Services and attempted to Start Apache Tomcat and I got an error 
message. The only thing the message meant to me is that Tomcat failed to start. 
I'm not an SME (Subject Matter Expert) on JAVA or Tomcat however if the content 
is important to resolve let me know.

I removed Java 8u421 from the Control Panel (Both the Jav SE Dev tool Kit and 
Java 8.421 (64-bit)).

I re-installed jdk-9.0.1_windows-64_bin.exe and checked Control Panel to 
confirm both Java and the toolkit was also installed.

I re-opened Services and was able to restart Apache Tomcat.

I then downloaded Java 8u422-b05-windows-x64 and using the same procedures as above 
uninstalled Java 9.0.1 and installed java 8.422 and it failed to start Apache Tomcat, so 
I once again had to revert to the "vulnerable" Java 9.0.1.

Can anyone tell me what non-vulnerable version of Java will work with Tomcat 
9.0.84 or what I am missing to make the 8.xx versions I have work? I can't 
simply upgrade Apache Tomcat as there are just too many developers entrenched 
in this version.


If you are using the Windows Service snap-in to start and stop Tomcat, 
then you likely need to update the service definition with the new path 
to Java. I don't think it auto-detects the Java version.


Run the tomcat9w.exe application and you should get a properties dialog 
which allows you to inspect the Tomcat service. If you have multiple 
Tomcat services, you may need to run "tomcat9w.exe //ES/servicename" 
from the command-line to get the right one.


In that properties dialog, you should be able to locate the path to Java 
and update it to match your newly-installed Java version.


-chris

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

Max parameters limit

2024-09-11 Thread Christopher Schultz


All,

Does anyone know if there is a way to limit the number of HTTP 
parameters in a POST request but explicitly allow more parameters for, 
say, a small set of specific URLs?


Asking for a friend.

-chris

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

Re: Tomcat 10.1 and context.xml

2024-09-10 Thread Christopher Schultz


Charlie,

On 9/10/24 16:12, charliedidon...@gmail.com wrote:

On 10/09/2024 20:21, charliedidon...@gmail.com wrote:

I have war file in Tomcat 10.1 with a context.xml file included in the
META-INF folder.

It's contents are





I am getting 404s from my app and was wondering if this is still
supported under 10.1 as it was under 9.0


Support is unchanged. From the 9.0.x docs:

The value of this field must not be set unless the Context element is defined 
in server.xml or the docBase is not located under the Host's appBase.

The above setting is not valid on any currently supported version of Tomcat 
including 9.0.x.

A check of the archives show that the same (or very similar) text exists in the 
docs all the way back to 5.5.

Mark

Weird because it did work under 9.0 with Spring MVC 4

Not sure if I understand your answer..but should I NOW place this in the 
server.xml? As my docBase is under the webapps folder which I understand to be 
my docBase by default

As follows





No, you should have:




If you want your application to be deployed on /codereaper then you 
should re-name the WAR file to codereaper.war (or WAR-like directory in 
webapps to "codereaper" - without quotes) in webapps/.


I'm pretty sure you don't even need a META-INF/context.xml file if it's 
so trivial. So I would delete it, re-name your WAR file (or dir) and try 
that.


-chris

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

Re: issue

2024-09-10 Thread Christopher Schultz


Lucas,

On 9/8/24 13:43, Lucas W wrote:

(Tomcat v 11.0.0, java v 22.0.2)

Hi,

System.out.println(..) works just after tomcat startup to
catalina.out. But at some point later on, souts fail to be logged to
catalina.out or anywhere. I am also experiencing something weird with
File.mkdirs(..); I have it in two different static functions in a
utility class, but it only works in one of them (I would give you some
sort of exception, but it seems exceptions arent logged to
catalina.out either, after the same point where sout stops working).

I will note that *sometimes* I get the following SEVEREs in
catalina.out on tomcat startup/deploy of my webapp:

SEVERE [Catalina-utility-2]
org.apache.catalina.startup.ContextConfig.beforeStart Exception fixing
docBase for context [] - java.util.zip.ZipException: zip END header
not found
SEVERE [Catalina-utility-2]
org.apache.catalina.startup.HostConfig.deployWAR Error deploying web
application archive
[/home/user/apache-tomcat-11.0.0-M24/webapps/ROOT.war] -
java.lang.IllegalStateException: Error starting child

(I am using maven with the build plugin maven-war-plugin to build the
war; this is the only maven build plugin I have) but otherwise, my
webapp runs smooth.

Any obvious potential causes?


My guess is that you've got a lot of logging-related JAR files in your 
application and that, at some point during your application's work, one 
gets loaded that takes over System.out and/or System.err.


If you have multiple *log*.jar files in WEB-INF/lib, I'd spend some time 
trying to determine whether or not you need all of them.


I just recently discovered that I had both slf4j-to-whatever AND 
whatever-to-slf4j in my own application in a test environment and was 
surprised to find it wasn't causing stack overflows.


-chris

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

Re: Nothing but 404 errors

2024-09-05 Thread Christopher Schultz


David,

On 9/5/24 11:40, David Rush wrote:

Darryl:

Do you have a script or something that copies the "needed files" from the
previous version to the new version?

Seems like you would need to copy all your webapps and any customizations
in your config files (I sometimes tweak my server.xml and
logging.properties).


The whole point of using CATALINA_BASE distinct from CATALINA_HOME is 
that you *do not need to copy such files*.


CATALINA_BASE must have its own conf/server.xml and it generally points 
to its own webapps/ directory. So, changing what's in CATALINA_HOME 
shouldn't disturb any of that.


-chris


On Thu, Sep 5, 2024 at 9:29 AM Darryl Baker 
wrote:


My method for updating Tomcat is that it lives behind a symbolic link.
/opt/tomcat/latest points to the version I want to run.
/opt/tomcat/apache-tomcat-9.0.XX when I want to upgrade I untar the latest
version, stop the running version, copy over the needed files to the new
version, repoint the link, and start up the new version. The system control
file use the symbolic link so needs no changes.

Darryl Baker, GSEC, GCLD (he/him/his)
Sr. System Administrator
Distributed Application Platform Services
Northwestern University
4th Floor
2020 Ridge Avenue
Evanston, IL 60208-0801
darryl.ba...@northwestern.edu 
(847) 467-6674 




On 9/5/24, 9:56 AM, "David Rush" > wrote:


Sebastian:


I want to keep HOME and BASE separate so that when a new version of Tomcat
comes out it's easy to swap the new binary download in at CATALINA_HOME
without impacting my configuration or webapps in CATALINA_BASE


David


On Thu, Sep 5, 2024 at 8:52 AM Sebastian Trost
mailto:m...@sebastiantrost.de.inva>lid>
wrote:



David,

On 05.09.2024 16:13, David Rush wrote:

My CATALINA_HOME is /opt/tomcat9/home (which is a symlink to
/opt/tomcat9/apache-tomcat-9.0.93)
My CATALINA_BASE is /var/opt/tomcat9

Why are you setting the CATALINA_BASE-variable? If you're running just
one Tomcat instance, this variable is not needed. Also, you point this
variable to a different directory?

See



https://urldefense.com/v3/__https://tomcat.apache.org/tomcat-10.1-doc/introduction.html
<
https://urldefense.com/v3/__https://tomcat.apache.org/tomcat-10.1-doc/introduction.html>*CATALINA_HOME_and_CATALINA_BASE__;Iw!!Dq0X2DkFhyF93HkjWTBQKhk!Rc7C8HkZWIbxfAm38rp_i-EV1fH7v3D-qSOqznnMXuPLPia3Lv6Ln8BmtPmJv0LMLNRTToWFeSGEIMSE9xhvPZvlufqjKXI$



Sebastian

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org 
users-unsubscr...@tomcat.apache.org>

For additional commands, e-mail: users-h...@tomcat.apache.org 
users-h...@tomcat.apache.org>






--


E-Mail to and from me, in connection with the transaction
of public
business, is subject to the Wyoming Public Records
Act and may be
disclosed to third parties.








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

Re: How to resolve 403 forbidden error in Tomcat level

2024-09-04 Thread Christopher Schultz


Jagadish,

On 8/30/24 10:52, jagadish sahu wrote:> Please find the attached text 
screenshot as you requested.


Okay, I'm going to be perfectly honest: I'm not going to download and 
read all those attachments. That's why I asked for plain-text.


If someone else is willing to go through all that, feel free.

I'm not going to go through a bunch of effort to provide free support.

-chris

On Fri, Aug 30, 2024 at 3:37 AM Christopher Schultz 
mailto:ch...@christopherschultz.net>> wrote:


Jadgish,

This list does not accept image attachments. We are not seeing what you
are posting. Please post text-only.

-chris

On 8/29/24 11:01, jagadish sahu wrote:
 > Hi Team and Christopher,
 >
 > We have attached a 403 error screenshot with full information.
 > The error seems to be generated from Tomcat level.
 >
 > We don't have any changes in the java code and our application is
 > working as expected in Tomcat 9.0.14.
 >
 > After upgrading to latest version Tomcat,we have been facing this
 > issue(Error communicating with web server status:403)
 >
 > Please find attached screenshot for authentication and web.xml.
 >
 > It would be great help if you provide a solution for this.
 >
 > Thanks,
 > Jagadish
 >
 >
 >
 > On Thu, Aug 29, 2024 at 6:30 PM Christopher Schultz
 > mailto:ch...@christopherschultz.net>
<mailto:ch...@christopherschultz.net
<mailto:ch...@christopherschultz.net>>> wrote:
 >
 >     Jagdesh,
 >
 >     On 8/29/24 06:29, jagadish sahu wrote:
 >      > We have tested our application in Apache tomcat 9.0.14. It is
 >     working as
 >      > expected, After upgrading from 9.0.14 to the latest
versions it
 >     is not
 >      > working.
 >      >
 >      >    When we leave the session for 30 mins, we will get some
 >     warning like
 >      > due to an inactive session, you can click on Ok to
continue the
 >     session,
 >      > after clicking Ok we are getting a 403 error message (attached
 >      > screenshot for your reference).
 >
 >     Your screenshot has been stripped from the list. Is this an
 >     application-generated 403 or one from Tomcat?
 >
 >      > The correct functionality is it should not get any error
message,
 >     after
 >      > clicking waring message it should redirect to login page
again,
 >     but in
 >      > the latest version of tomcat its not working, so we are
 >     contacting you
 >      > people.
 >      >
 >      > Please provide a solution/ workaround for this issue.
 >
 >     What kind of authentication are you using? What kind of login
mechanism
 >     are you using -- e.g. FORM versus HTTP BASIC/DIGEST, etc.?
 >
 >     Can you post the relevant parts of your web.xml?
 >
 >     -chris
 >
 >   
  -

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

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
<mailto:users-unsubscr...@tomcat.apache.org>
For additional commands, e-mail: users-h...@tomcat.apache.org
<mailto: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 Upgrade to address Curl and libcurl vulnerabilities

2024-08-30 Thread Christopher Schultz


John,

On 8/30/24 10:15, Kenan, John wrote:

Please advise when an update to Apache Tomcat will be released that
addresses the following Curl and libcurl security vulnerabilities:

Critical:
CVE-2023-38545

High:
CVE-2024-7264

Medium:
CVE-2023-46218
CVE-2023-46219
CVE-2024-0853

Low:
CVE-2023-38546


Apache Tomcat doesn't use curl or libcurl.

Is there something specific you'd like to be addressed?

-chris

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

Re: How to resolve 403 forbidden error in Tomcat level

Jadgish,

This list does not accept image attachments. We are not seeing what you 
are posting. Please post text-only.

-chris

On 8/29/24 11:01, jagadish sahu wrote:

Hi Team and Christopher,

We have attached a 403 error screenshot with full information.
The error seems to be generated from Tomcat level.

We don't have any changes in the java code and our application is 
working as expected in Tomcat 9.0.14.

After upgrading to latest version Tomcat,we have been facing this 
issue(Error communicating with web server status:403)

Please find attached screenshot for authentication and web.xml.

It would be great help if you provide a solution for this.

Thanks,
Jagadish

On Thu, Aug 29, 2024 at 6:30 PM Christopher Schultz 
mailto:ch...@christopherschultz.net>> wrote:

Jagdesh,

On 8/29/24 06:29, jagadish sahu wrote:
 > We have tested our application in Apache tomcat 9.0.14. It is
working as
 > expected, After upgrading from 9.0.14 to the latest versions it
is not
 > working.
 >
 >    When we leave the session for 30 mins, we will get some
warning like
 > due to an inactive session, you can click on Ok to continue the
session,
 > after clicking Ok we are getting a 403 error message (attached
 > screenshot for your reference).

Your screenshot has been stripped from the list. Is this an
application-generated 403 or one from Tomcat?

 > The correct functionality is it should not get any error message,
after
 > clicking waring message it should redirect to login page again,
but in
 > the latest version of tomcat its not working, so we are
contacting you
 > people.
 >
 > Please provide a solution/ workaround for this issue.

What kind of authentication are you using? What kind of login mechanism
are you using -- e.g. FORM versus HTTP BASIC/DIGEST, etc.?

Can you post the relevant parts of your web.xml?

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
<mailto:users-unsubscr...@tomcat.apache.org>
For additional commands, e-mail: users-h...@tomcat.apache.org
<mailto: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 takes over 1 minute to stop


Quoc,

On 8/29/24 15:23, Quoc Nguyen wrote:

Thank you Mr. Thomas !!!

Yes sir !!! I noticed that a clean Tomcat 9.0.93 install (as with other 9.0.9x 
versions) stops around 1s. I believe that it is so because it has no managed 
web apps/resources. Just Tomcat itself. I could be wrong.

Yes, I noticed that there are warnings of non-daemon threads that weren't 
stopped in catalina.log.  I read somewhere that they're just warnings; thus 
don't affect this process.

There are no requests running at all while stopping Tomcat. Essentially, 
install/deploy different versions (9.0.89, 9.0.9x) of Tomcat with the same set 
of non-changing web apps and stop Tomcat via Windows service and record the 
stop times.

Yes, I took the thread dumps while stopping version 9.0.90. There is a thread 
"DestroyJavaVM" that, after a few seconds after Tomcat receives the shutdown 
signal (maybe after it's done stopping its main stuff), was running for 60s.

That said, there're no explanations for what happened:

a) between version 9.0.13 and 9.0.14 with the introduction of "..scheduled executor 
to the Server..", which has default wait time of 60s and forces a Timeout in 
Tomcat9w.exe to get Tomcat stop under 60s.
b) between version 9.0.89 and 9.0.90 after the upgrade of Apache Commons Daemon 
procrun to version 1.4.0.0, which has a default pause of 60s.

More work/data to confirm: I'm working with Tomcat version 9.0.89 and 9.0.90 
(where I noticed the change) in two different boxes.

For version 9.0.90 box: started and stopped. Daemon logs below.

Note:

* Apache Commons Daemon procrun (1.4.0.0 64-bit)
* exactly 60s wait until finished regardless of the Timeout set in Tomcat9w.exe

[2024-08-29 13:41:58] [info]  [13472] Apache Commons Daemon procrun (1.4.0.0 
64-bit) started.
[2024-08-29 13:41:58] [info]  [13472] Running Service 'Tomcat9'...
[2024-08-29 13:41:58] [info]  [ 9148] Starting service...
[2024-08-29 13:41:58] [error] [12380] Could not create instance of 
java/io/FileOutputStream
[2024-08-29 13:41:59] [info]  [ 9148] Service started in 1636 milliseconds.
[2024-08-29 13:42:40] [info]  [13472] Service SERVICE_CONTROL_STOP signalled.
[2024-08-29 13:42:40] [info]  [11996] Stopping service...
[2024-08-29 13:43:06] [info]  [11996] Service stop thread completed.
[2024-08-29 13:44:06] [info]  [13472] Run service finished.
[2024-08-29 13:44:06] [info]  [13472] Apache Commons Daemon procrun finished.


For version 9.0.90 box: switched version 9.0.89 of Tomcat9.exe into this box. 
Started and stopped. Daemon logs below.

Note:

* Apache Commons Daemon procrun (1.3.4.0 64-bit)
* stop time is definitely less than 60s if the Timeout set in Tomcat9w.exe is 
less than 60 and ~63s (or 1 min 3 secs as reported)  when set to 0 (out of the 
box)
* the last two log lines of "out of the box" don't appear in the log for 
Timeout being set to 5. Speculation: the process is short-circuited taking into account 
the set Timeout.

The Timeout was set for 5:

[2024-08-29 14:08:04] [info]  [11012] Apache Commons Daemon procrun (1.3.4.0 
64-bit) started.
[2024-08-29 14:08:04] [info]  [11012] Running Service 'Tomcat9'...
[2024-08-29 14:08:04] [info]  [14356] Starting service...
[2024-08-29 14:08:05] [error] [ 6740] Could not create instance of 
java/io/FileOutputStream
[2024-08-29 14:08:06] [info]  [14356] Service started in 1648 milliseconds.
[2024-08-29 14:08:47] [info]  [11012] Service SERVICE_CONTROL_STOP signalled.
[2024-08-29 14:08:47] [info]  [14432] Stopping service...
[2024-08-29 14:08:58] [info]  [14432] Service stop thread completed.


The Timeout was set for 0 (out of the box):

[2024-08-29 14:43:51] [info]  [ 8848] Apache Commons Daemon procrun (1.3.4.0 
64-bit) started.
[2024-08-29 14:43:51] [info]  [ 8848] Running Service 'Tomcat9'...
[2024-08-29 14:43:51] [info]  [ 8796] Starting service...
[2024-08-29 14:43:52] [error] [ 1688] Could not create instance of 
java/io/FileOutputStream
[2024-08-29 14:43:53] [info]  [ 8796] Service started in 1641 milliseconds.
[2024-08-29 14:44:47] [info]  [ 8848] Service SERVICE_CONTROL_STOP signalled.
[2024-08-29 14:44:47] [info]  [15996] Stopping service...
[2024-08-29 14:45:00] [info]  [15996] Service stop thread completed.
[2024-08-29 14:46:00] [info]  [ 8848] Run service finished.
[2024-08-29 14:46:00] [info]  [ 8848] Apache Commons Daemon procrun finished.


All that said, I believe the procrun version is the difference.

Greatly appreciate your help !!!


The non-daemon threads are highly likely to be involved in this. I'm not 
sure why you weren't having any issues in previous versions of Tomcat.


You should definitely try to fix those whether or not they are related 
to this 1-minute stop.


What "timeout" are you setting in Tomcat9w.exe?

-chris

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

Re: Tomcat 10.1 Http11NioProtocol with the OpenSSLImplementation does not sent close_notify in response to client's close_notify


Isaac,

On 8/26/24 13:24, Isaac Klickstein wrote:

What is the "Tomcat Native Client"?


I am using the Tomcat Native software (maybe "client" was wrong) available here 
to build the OpenSSLImplementation:
https://tomcat.apache.org/download-native.cgi#2.0.8

I then link to this library using LD_LIBRARY_PATH in the Tomcat's setenv.sh 
script.


Aah, okay. You are just using libtcnative on the server side. curl is 
the client.



How do you trigger this behavior? Just any request like "curl


I have been using the manager app, something like

curl --cacert  --url 'https://:/manager/text/list' --user robot:robotpw

but any request to the ROOT/manager/other hosted would do.

I have been breaking down the behavior based on protocol=NIO/NIO2/APR and the 
sslImplementationName JSSE/OpenSSL

NIO/NIO2+JSSE = good
NIO/NIO2+OpenSSL = bad
APR+OpenSSL = good


That's interesting. When using APR+OpenSSL, the Tomcat code is entirely 
responsible for the connection management (e.g. socket, buffers, etc.) 
and the crypto (using OpenSSL, of course).


When using NIO+OpenSSL, Java is responsible for the connection 
management AND the orchestration of the use of the cryptographic module. 
The use of OpenSSL versus some other cryptographic module (e.g. built-in 
JSSE) should not affect whether a close_notify is sent. :/



I have TCP dumps for each of these configurations saved and could upload them 
as well as the configuration of the connectors.


Is a TCP dump required to observe this behavior, or will e.g. curl -vvv 
show it as well?


Is this causing any actual issues in your environment, or are you more 
reporting a spec violation that needs to be cleaned-up. It seems to be 
that if the client asks the server to close the connection, if the 
connection is closed then it's closed whether or not this particular 
message is transmitted before termination of the connection.


-chris


On Monday, August 26th, 2024 at 11:40 AM, Christopher Schultz 
 wrote:


Isaac,

On 8/25/24 13:27, Isaac Klickstein wrote:


Hello Tomcat Users

Tomcat Version: 10.1.28
OpenSSL version: 3.0.14
Tomcat Native Client: 2.0.8



What is the "Tomcat Native Client"?


I have configured an HTTPS connector with the 
org.apache.coyote.http11.Http11NioProtocol protocol and the 
org.apache.tomcat.util.net.openssl.OpenSSLImplementation sslImplementationName 
using TLSv1.2

When I tcpdump any request to this connector, Tomcat is not returning a 
"close_notify" in response to a client's close_notify, and I cannot figure out 
how to force Tomcat to return a close_notify. This seems to be a violation of the TLS 
protocol which demands both sides issue a close_notify.



Careful: both the client and the server are always allowed to be
powered-off before they respond to any network stimulus. This is what
timeouts are for. TLS cannot place any more requirements on the network
peers than TCP has already done.


Recreating this situation, as far as I can tell, only requires combining the 
Http11NioProtocol with the OpenSSLImplementation (Tomcat9 or Tomcat10, TLSv1.2 
or TLSv1.3, OpenSSL 3.0, 3.1, and 3.2, all exhibit this behavior).



How do you trigger this behavior? Just any request like "curl
https://example.com/"; ?


Other notes, switching the sslImplementationName to 
org.apache.tomcat.util.net.jsse.JSSEImplementation does return a close_notify 
by the server in response to the client's close_notify.

Also, switching back to Tomcat9, and using the 
org.apache.coyote.http11.Http11AprProtocol, Tomcat also returns a close_notify 
in response to a client's close_notify.

I have run out of ideas, googling this behavior has turned up nothing related 
to Tomcat (although there does appear to be a similar behavior noticed in Netty 
also using the OpenSSLEngine https://github.com/netty/netty/issues/6167)

Any help would be greatly appreciated, I am happy to send along any other 
information that would be informational for diagnostics



So...

Tomcat 10.1 + NIO/JSSE+OpenSSLImplementation+tcnative = bad
Tomcat 9.0 + APR+tcnative = good
Tomcat 9.0 + NIO/JSSE+OpenSSLImplementation+tcnative = ?

-chris

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


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



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

Re: How to resolve 403 forbidden error in Tomcat level


Jagdesh,

On 8/29/24 06:29, jagadish sahu wrote:
We have tested our application in Apache tomcat 9.0.14. It is working as 
expected, After upgrading from 9.0.14 to the latest versions it is not 
working.


   When we leave the session for 30 mins, we will get some warning like 
due to an inactive session, you can click on Ok to continue the session, 
after clicking Ok we are getting a 403 error message (attached 
screenshot for your reference).


Your screenshot has been stripped from the list. Is this an 
application-generated 403 or one from Tomcat?


The correct functionality is it should not get any error message, after 
clicking waring message it should redirect to login page again, but in 
the latest version of tomcat its not working, so we are contacting you 
people.


Please provide a solution/ workaround for this issue.


What kind of authentication are you using? What kind of login mechanism 
are you using -- e.g. FORM versus HTTP BASIC/DIGEST, etc.?


Can you post the relevant parts of your web.xml?

-chris

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

Re: Tomcat takes over 1 minute to stop

2024-08-27 Thread Christopher Schultz


Quoc,

On 8/27/24 14:58, Quoc Nguyen wrote:

Apache Tomcat version: 9.0.90 and above
OS: Windows Server 2019

Tomcat Version Used Time Taken to stop

Apache Tomcat/8.5.66~ 9 seconds
Apache Tomcat/9.0.1 ~ 9 seconds
Apache Tomcat/9.0.10~ 9 seconds
Apache Tomcat/9.0.13~ 9 seconds
Apache Tomcat/9.0.14~ 1 min 3 secs
Apache Tomcat/9.0.16~ 1 min 3 secs
Apache Tomcat/9.0.20~ 1 min 3 secs
Apache Tomcat/9.0.30~ 1 min 3 secs
Apache Tomcat/9.0.40~ 1 min 3 secs
Apache Tomcat/9.0.44~ 1 min 3 secs
Apache Tomcat/9.0.46~ 1 min 3 secs
Apache Tomcat/9.0.75~ 1 min 3 secs
Apache Tomcat/9.0.89~ 1 min 3 secs
Apache Tomcat/9.0.90~ 1 min 3 secs
Apache Tomcat/9.0.93~ 1 min 3 secs

 From Tomcat changelog 
(https://tomcat.apache.org/tomcat-9.0-doc/changelog.html#Tomcat_9.0.14_(markt): Version 
9.0.14 "Add a scheduled executor to the Server, which can be used to process 
periodic utility tasks. The utility threads are non daemon by default. (remm)", 
which has the default timeout of 60s for procrun.

Workaround: to reduce the default timeout of 60s, I can supply it via Tomcat 
Monitor (Tomcat9w.exe) or while creating the Windows service.

This workaround has worked up to version 9.0.89 and has stopped for version 
9.0.90 and above. The difference is version 9.0.89 and lower uses Apache 
Commons Daemon procrun (1.3.x.0 64-bit)  whereas version 9.0.90 and above uses 
Apache Commons Daemon procrun (1.4.0.0 64-bit).

Questions:

1) Am I on the right rack with this procrun timeout?

2) If #1 is yes, does the upgrade from Apache Commons Daemon procrun (1.3.x.0 
64-bit) to Apache Commons Daemon procrun (1.4.0.0 64-bit) cause the supplied 
timeout to be ignored so that the default of 60s is always in effect?

2) If #2 is yes, is there a workaround while waiting for a fix or must wait for 
a fix?


Since this symptom lasts for more than a minute and (I assume) is 
trivially reproducible, you should take a thread dump to find out what 
Tomcat is doing during that time.


-chris

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

Re: Tomcat 10.1 Http11NioProtocol with the OpenSSLImplementation does not sent close_notify in response to client's close_notify


Isaac,

On 8/25/24 13:27, Isaac Klickstein wrote:

Hello Tomcat Users

Tomcat Version: 10.1.28
OpenSSL version: 3.0.14
Tomcat Native Client: 2.0.8


What is the "Tomcat Native Client"?


I have configured an HTTPS connector with the 
org.apache.coyote.http11.Http11NioProtocol protocol and the 
org.apache.tomcat.util.net.openssl.OpenSSLImplementation sslImplementationName 
using TLSv1.2

When I tcpdump any request to this connector, Tomcat is not returning a 
"close_notify" in response to a client's close_notify, and I cannot figure out 
how to force Tomcat to return a close_notify. This seems to be a violation of the TLS 
protocol which demands both sides issue a close_notify.


Careful: both the client and the server are always allowed to be 
powered-off before they respond to any network stimulus. This is what 
timeouts are for. TLS cannot place any more requirements on the network 
peers than TCP has already done.



Recreating this situation, as far as I can tell, only requires combining the 
Http11NioProtocol with the OpenSSLImplementation (Tomcat9 or Tomcat10, TLSv1.2 
or TLSv1.3, OpenSSL 3.0, 3.1, and 3.2, all exhibit this behavior).


How do you trigger this behavior? Just any request like "curl 
https://example.com/"; ?



Other notes, switching the sslImplementationName to 
org.apache.tomcat.util.net.jsse.JSSEImplementation does return a close_notify 
by the server in response to the client's close_notify.

Also, switching back to Tomcat9, and using the 
org.apache.coyote.http11.Http11AprProtocol, Tomcat also returns a close_notify 
in response to a client's close_notify.

I have run out of ideas, googling this behavior has turned up nothing related 
to Tomcat (although there does appear to be a similar behavior noticed in Netty 
also using the OpenSSLEngine https://github.com/netty/netty/issues/6167)

Any help would be greatly appreciated, I am happy to send along any other 
information that would be informational for diagnostics


So...

Tomcat 10.1 + NIO/JSSE+OpenSSLImplementation+tcnative = bad
Tomcat 9.0 + APR+tcnative = good
Tomcat 9.0 + NIO/JSSE+OpenSSLImplementation+tcnative = ?

-chris

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

Re: j_security_check error

Mark,

On 8/16/24 11:38, Mark Thomas wrote:

On 16/08/2024 16:16, Fernando wrote:

Hi all,
I need help with problem that I can't fix.
I am using Apache Tomee 8, but I know that Apache Tomee rest on Apache
Tomcat, in this case version 9.
My problem is when some user exit from application this forward to login
page doing this:
HttpSession session = request.getSession();
session.invalidate();

request.getRequestDispatcher("/login.jsp").forward(request,
response);

then if same user try to login, this launch something like this:
http://localhost:8080/appweb/privado/j_security_check

Asking in other forums, I read that " when you use JEE-standard
Container
security, the user should not explicitly request the login/loginfail
pages.

It won't work right."

That is correct. Some implementations have additional configuration
options so this doesn't break but you would be better forwarding to a
default page that requires authentication. The FORM auth will do its thing.

However I have other applicacion running on payara and that works, then I
start to think that maybe is something misconfigured...
Someone has some idea about this problem?

https://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Form_Authenticator_Valve/Attributes

Look for "landingPage"

Or...

https://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Form
Authenticator Valve_Attributes_landingPage

-chris

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

Re: How to Prevent Dynamic Code manipulation via Java Attach API for Tomcat


Bhavesh,

On 8/15/24 14:49, Bhavesh Mistry wrote:

I recently came to know that with Java Attach API, anyone with access can
attach to a local process and manipulate Java Byte code.

For example, password harvesting is attached to the Filter Chain.
https://github.com/rebeyond/memShell

What I found is to run JVM with *-XX:+DisableAttachMechanism*, but the
problem it will disable jstack,jcmd, etc all debug tools that are needed to
debug Application issues.

Do you guys any recommendations and how to add authentication to Java
Attach API?


Java Attach API requires one of the following:

1. Agent specified at JVM launch time (e.g. -javaagent)

2. Agent attached at runtime /as the same OS user/

3. Agent attached at runtime as root

That's already a pretty high bar for security. If your attacker has 
root, it's already game over. If your attacker has login as the Tomcat 
user, they can presumably stop, start, and deploy any code into Tomcat 
already. Access to the JVM via the Attach API is no more concerning than 
having access to the Tomcat user.


-chris

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

Re: Might switching to Tomcat 9 solve this?





On 8/15/24 12:40, Chuck Caldarale wrote:



On Aug 15, 2024, at 11:20, James H. H. Lampert 
 wrote:

In the wake of my recently switching a customer over from 8.5 to 9.0, a 
question came up about another customer installation.

They are quite possibly the most heavily loaded customer installation we have 
(and they also have a chronic problem with disk space).

They have a chronic problem with our webapp overloading and locking up, forcing 
a Tomcat restart (and worse, when it's in this state, it takes a long time to 
shut down). Nobody else has that problem.



Assuming that AS/400 uses some form of paging, is real memory also overloaded, 
causing heavy swap file usage? Slow shutdown can happen due to having to page 
in chunks of the process that aren’t used during normal running.



Is there a chance that going to 9.0 would help? Is there a chance that doing so 
would make it worse?



Really not possible to say. I would expect the performance effects of changing 
Tomcat versions would be rather small unless it’s noted in the changelog. 
Updating the JVM might well have a larger impact, but that’s also not easy to 
predict.


+1

I would say that if an issue in Tomcat is responsible for whatever is 
happening in your environment, using Tomcat 9 is likely to get you into 
a better position to upgrade to a fixed-version since Tomcat 8.5 reached 
EOL a few months ago.


-chris

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

Re: Refresh my memory: Any "gotchas" in going from Tomcat 8.5 to Tomcat 9?


James,

On 8/15/24 11:12, James H. H. Lampert wrote:

On 8/14/24 6:12 PM, Chuck Caldarale wrote:


The blocking IO implementation (http11.Http11Protocol) was actually
removed in 8.5, but if specified in the config, 8.5 would substitute
the default non-blocking one (http11.Http11NioProtocol). In 9.0, this
auto-substitution was removed, requiring a valid protocol
specification to be used.


I vaguely remember being told something like that when I put our cloud 
box on Tomcat 9, and had to make the same change.


My guess is that this is the change that may cause you the most trouble:

"
The default CookieProcessor is now the Rfc6265CookieProcessor. The
CookieProcessor is configurable per Context and the
LegacyCookieProcessor may be used to obtain the 8.0.x behaviour.
"

I would leave the configuration default the way it is, but remember that 
the old cookie behavior can be restored using the Legacy processor.


It would be better to fix the application and/or clients if at all 
possible, but the Legacy cookie processor is there in case you panic. :)


-chris

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

Re: Web browser clocking issue at Apache Tomcat 10.1.20 on Linux


Tim,

On 8/15/24 10:55, Tim Zielke wrote:

When the web browser clocking issue happens, the web browser will
just clock when I click on a link in this application and then
eventually time out on the browser side.


When you say "clock"

Do you mean "the browse throbber just keeps going and going and never 
gets a response"? I googled for "browser clocking" and all synonyms I 
could think of and I have no idea what you mean.


Do you just mean you make a request and never get a response?


The TCP connections mentioned in original posting represent this web
browser click that clocked and eventually timed out at the browser.
The Spring Boot trace is showing that the https request are making it
to the server side socket and nio-exec threads are starting to act on
it. There are several nio-exec threads doing a read register on the
socket (within the same millisecond), but then nothing else happens
with the socket.

Are you able/willing to post a thread dump?


There is no nio-exec write register or reading/processing https data
from the socket. After 60 seconds, the connections are closed due to
the server.tomcat.keep-alive-timeout default setting.

Anything in the log files other than what you previously posted?

You said this application works in other environments, and that this 
environment had "different security requirements". Can you share the 
differences between those other (working) environments and this 
differently-configured one?


-chris


-Original Message-
From: Mark Thomas 
Sent: Thursday, August 15, 2024 9:35 AM
To: users@tomcat.apache.org
Subject: Re: Web browser clocking issue at Apache Tomcat 10.1.20 on Linux

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

[External]

On 15/08/2024 14:36, Tim Zielke wrote:




web browser clocking issues




Can you clarify what you mean by this please.

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



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

Re: Migration to Tomcat Assistance


Melvin,

On 8/13/24 16:35, Baez, Melvin L wrote:

Hi all,

I’m reaching out to the community seeking assistance. I support Tomcat 
from an infrastructure perspective and assist our developers with 
migrating a set of existing applications from WebSphere and TomEE to 
Tomcat as the application web server.


We are trying to come up with a streamlined process of helping 
applications move to Tomcat, while accommodating their specific 
requirements.


I’m looking for utilities, scripts, cheatsheets that can assist us. 
Also, if there are other references of mapping libraries/jar files to 
features that would be helpful.


I think here would be a great place to start:

https://tomee.apache.org/comparison.html

This will help you understand which applications need TomEE (and perhaps 
additional components not already provided by one of their several 
distributions) and which can be deployed on a vanilla Tomcat. Some 
applications can probably be deployed on a 
Tomcat-plus-a-small-number-of-support-libraries without requiring all of 
TomEE. Your developers should be able to help with this decision.


As for migration... just copy the WAR file from WebSphere and drop it 
into Tomcat's webapps/ directory and you should be good for the most 
part. except configuration. My brief experience with Java EE was 
that each server seemed to have endless configuration that needed to be 
done with the environment to support the application. If the application 
relies on lots of container-provided resources such as JNDI, then you 
will need to migrate that stuff by hand. The Tomcat team doesn't 
maintain anything I know of that would help you migrate from WebSphere 
configuration to Tomcat (or TomEE) configuration.


That said, most of this stuff ends up being XML-based, so if you have a 
number of configurations to migrate, we could help you identify the kind 
of configuration you will need in Tomcat/TomEE and you could write an 
XSL transform to take your existing configuration and mutate it into 
whatever is required for Tomcat/TomEE.


Hope that helps,
-chris

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

Re: mod_jk retry continuing existing stream?


Jess,

On 8/12/24 14:54, Holle, Jess wrote:

I have mod_jk load balancing over several back-end Java processes which embed 
Tomcat.

When I Ctrl-C one of those processes, a server-sent-event response stream 
(which has already sent a number of events) does not end from a client 
perspective.  Rather the original request is retried against the next server 
and its response is simply added to the original stream from the client's 
perspective.

That is just plain weird - and doesn't make sense to me at all in terms of 
retry handling.

Any pointers/info on this would be much appreciated.

--
Jess Holle

P.S. The stream is generated via async servlet request/response via Spring 
WebFlux/Reactor.


Does this happen with all requests, or only those which the HTTP spec 
defines to be idempotent?


-chris

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

Re: [Semi OT] Suggestion: Maven repository for Tomcat native library


Harri,

On 8/12/24 03:26, Harri Pesonen wrote:

Tomcat native gives much better SSL connection performance, they say.
At least in Windows. I have not personally performed any tests though.

https://tomcat.apache.org/tomcat-9.0-doc/apr.html


I would love for you to do some of your own benchmarking to confirm.

If you are using libtcnative along with the NIO connector (which is the 
default configuration for Tomcat 9), then you are not using APR for 
sockets, buffers, and such. This will perform identically to the 
Java-provided cryptographic provider-based connector (for the sockets 
and buffers) but may have fewer buffer-copies in- and out- of the native 
realm. So a potential performance improvement over the APR connector.


Anyway.

The libtcnative library of course uses OpenSSL for cryptographic 
primitives which have historically been much faster than those provided 
by Java. IIRC, jfclere identified a JVM bug which causes older versions 
of Java to fail to detect hardware support for certain cryptographic 
algorithms (specifically, AES!) which caused the software-based 
implementation to be used instead. Also IIRC, jfclere says that this has 
been fixed "in recent JVMs" but I'm not sure of the details of which 
version(s) contain such a fix.


So I'd be quite happy to see if you see any significant difference 
between the two connectors (NIO+OpenSSL and NIO+JSSE) in your 
environment, Java version, etc.


-chris


-Original Message-----
From: Christopher Schultz 
Sent: lauantai 10. elokuuta 2024 0.51
To: users@tomcat.apache.org
Subject: Re: [Semi OT] Suggestion: Maven repository for Tomcat native library

Harri,

On 8/9/24 05:56, Harri Pesonen wrote:

Hello, currently Tomcat native library needs to be downloaded manually from 
here:

https://tomcat.apache.org/download-native.cgi

It would be better to download it from Maven repository, so that we could 
upgrade the version easier using Maven scripts.
Also we could see easier when the version needs to be upgraded.
Normally Maven repository contains only Java artifacts, but it is possible to 
upload binaries as well.
For example Microsoft JDBC driver has Java .jar in on artifact, and native .dll 
in separate artifact:

https://mvnrepository.com/artifact/com.microsoft.sqlserver/mssql-jdbc_auth/12.8.0.x64

What say you?


I'm just academically curious: what do you need tcnative for?

-chris

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


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



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

Re: Tomcat 9 and OpenJDK 17

2024-08-09 Thread Christopher Schultz


Jenny,

On 8/9/24 15:03, Ying Jin wrote:

We have a web application implemented with JSF 2.3, Primefaces, JDK11 and
it can run well on Tomcat 9 Server. We encountered following errors after
upgrading JDK version to OpenJDK17 in order to meet the deployment
requirements:

SEVERE: A child container failed during start
java.util.concurrent.ExecutionException:
org.apache.catalina.LifecycleException: Failed to start component
[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/SpaceSurvey]]
at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
at
org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:878)
at
org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:795)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1332)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1322)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
at
java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:145)
at
org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:871)
at
org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:249)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at
org.apache.catalina.core.StandardService.startInternal(StandardService.java:428)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at
org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:914)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at org.apache.catalina.startup.Catalina.start(Catalina.java:772)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:342)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:473)
Caused by: org.apache.catalina.LifecycleException: Failed to start
component
[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/SpaceSurvey]]
at
org.apache.catalina.util.LifecycleBase.handleSubClassException(LifecycleBase.java:440)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:198)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1332)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1322)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
at
java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:145)
at
org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:871)
... 21 more
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
protected final java.lang.Class
java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int) throws
java.lang.ClassFormatError accessible: module java.base does not "opens
java.lang" to unnamed module @800a742
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
at java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
at org.jboss.weld.util.bytecode.ClassFileUtils$1.run(ClassFileUtils.java:67)
at
java.base/java.security.AccessController.doPrivileged(AccessController.java:569)
at
org.jboss.weld.util.bytecode.ClassFileUtils.makeClassLoaderMethodsAccessible(ClassFileUtils.java:60)
at org.jboss.weld.bootstrap.WeldStartup.startContainer(WeldStartup.java:220)
at
org.jboss.weld.bootstrap.WeldBootstrap.startContainer(WeldBootstrap.java:72)
at
org.jboss.weld.bootstrap.WeldBootstrap.startContainer(WeldBootstrap.java:67)
at
org.jboss.weld.environment.servlet.WeldServletLifecycle.initialize(WeldServletLifecycle.java:183)
at
org.jboss.weld.environment.servlet.EnhancedListener.onStartup(EnhancedListener.java:62)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:4936)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
... 27 more

Please help shed some lights on this issue. What is the quick way to get
this project to work with OpenJDK 17 under time pressure?


This looks like a JBoss issue to me, given the stack trace.

If you are already running the latest version of JBoss available,

Re: [Semi OT] Suggestion: Maven repository for Tomcat native library

2024-08-09 Thread Christopher Schultz


Harri,

On 8/9/24 05:56, Harri Pesonen wrote:

Hello, currently Tomcat native library needs to be downloaded manually from 
here:

https://tomcat.apache.org/download-native.cgi

It would be better to download it from Maven repository, so that we could 
upgrade the version easier using Maven scripts.
Also we could see easier when the version needs to be upgraded.
Normally Maven repository contains only Java artifacts, but it is possible to 
upload binaries as well.
For example Microsoft JDBC driver has Java .jar in on artifact, and native .dll 
in separate artifact:

https://mvnrepository.com/artifact/com.microsoft.sqlserver/mssql-jdbc_auth/12.8.0.x64

What say you?


I'm just academically curious: what do you need tcnative for?

-chris

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

Re: Upgraded Tomcat 9.0.82 to 10.1.23 getting HTTP response 400 for pipe characters in URL

2024-08-08 Thread Christopher Schultz


Chuck,

On 8/8/24 09:58, Chuck Caldarale wrote:



On Aug 8, 2024, at 08:46, Christopher Schultz  
wrote:

On 8/8/24 05:20, Patil, Tushar wrote:

In older version [9.0.82]:
 
In newer version[10.1.23]:



IMPORTANT NOTE: You have posted your "requiredSecret" value and may want to 
change that now that it is public.

I'm not sure why you would not have needed these in the past, but you might need to add 
relaxedPathChars="|" in your  configuration to allow these pipes.

If the pipes are also appearing in your query string, you may need to set 
relaxedQueryChars to the same value.



The AJP connector documentation does not show relaxedPathChars nor 
relaxedQueryChars as valid configuration items - these are only in the HTTP/1.1 
connector. I thought that the AJP connector expected the front end to do URL 
validation.


+1

I hadn't noticed the AJP in there until after I had written most of the 
reply, then went back to add info about the secret and reverse proxy. Oops.


-chris

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

Re: Apache Tomcat Memory Allocation

2024-08-08 Thread Christopher Schultz


Sagar,

On 8/8/24 05:47, Mark Thomas wrote:

On 08/08/2024 10:40, Sagar Palle wrote:

Hi,

I have installed the tomcat version *tomcat-9.0.84 *in the window 
system, it is consuming 29GB memory, and we configure the memory in 
the catalina.bat(C:\tomcat-9.0.84\bin) 24GB, it is still consuming the 
29GB memory.


That is entirely expected.

"Maximum Java Heap Space" < "Maximum Memory used by Java Process"


The Java Runtime Environment uses more memory than what's in the Java 
heap. For example, there is a compiler which compiles your Java code 
into machine code, and that code has to go into memory somewhere. Also, 
the Garbage Collector has some overhead of managing the heap itself, and 
that information cannot go into the heap. (Okay, some of it can, but 
some cannot.) Native libraries do not use the Java heap. The JVM itself 
uses the Java heap for some things, but off-heap memory for other things.


I've seen JVM processes that use ~50% non-heap memory. Those are extreme 
cases, but it does happen.



*OS Details:*


This mailing lists drops images. Use plain text.

Can you please suggest where we need to configure the  memory for the 
Apache tomcat service.


You should not edit catalina.bat. Use setenv.bat.


+1

-chris

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

Re: Upgraded Tomcat 9.0.82 to 10.1.23 getting HTTP response 400 for pipe characters in URL

2024-08-08 Thread Christopher Schultz


Tushar,

On 8/8/24 05:20, Patil, Tushar wrote:

In older version [9.0.82]:
 



In newer version[10.1.23]:



IMPORTANT NOTE: You have posted your "requiredSecret" value and may want 
to change that now that it is public.


I'm not sure why you would not have needed these in the past, but you 
might need to add relaxedPathChars="|" in your  configuration 
to allow these pipes.


If the pipes are also appearing in your query string, you may need to 
set relaxedQueryChars to the same value.


Did you upgrade your reverse proxy as well, or only Tomcat?

-chris



From: Mark Thomas 
Sent: Thursday, August 8, 2024 2:31 PM
To: users@tomcat.apache.org 
Subject: Re: Upgraded tomcat 9.0.82 to 10.1.23 getting HTTP resonse 400 for 
pipe charactets in URL

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

On 08/08/2024 08:19, Patil, Tushar wrote:

Hi Team,

After upgrading Apache Tomcat from 9.0.82 to 10.1.23, we started getting HTTP 
response 400 if the URL contains a pipe(|) character.

According to the reference provided below, Apache made some related changes, 
but these were implemented in versions 8.5.6 and earlier. Currently, we are not 
able to figure out why we started getting this problem in 10.1.23.
Reference: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.redhat.com%2Fshow_bug.cgi%3Fid%3D1397484&data=05%7C02%7Ctuspatil%40ptc.com%7Cfaa92529fa2d4cb6c8c708dcb788f44b%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C638587046060925564%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=X8H9WyT9rsf9dplGtgHaNIjo2NK1wUhRrX5EbOe80Yo%3D&reserved=0

Please help us to figure out the reason for the same.


Please provide the HTTP connector settings you used with both Tomcat
versions.

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: module-info.class missing in tomcat-servlet-api v10.1.26

2024-08-06 Thread Christopher Schultz


All,

On 8/6/24 09:02, Chuck Caldarale wrote:



On Aug 6, 2024, at 07:50, Georg Kunkemöller  
wrote:

i upgraded my  tomcat-servlet-api from 10.1.25 to 10.1.26 and noticed that
between those 2 the module-info.class went missing which breaks my
application which requires the jakarta.servlet module. I could also not
find it i a subdirectory somewhere. Was this change intentional?



Fixed in 10.1.27, which will be released very shortly (possibly today).

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


It's actually 10.1.28 (10.1.27 was skipped) but I have just released it. 
Enjoy!


-chris

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

Re: Apache Tomcat Plain Password

2024-08-05 Thread Christopher Schultz


Chuck,

On 8/3/24 12:17, Chuck Caldarale wrote:



On Aug 3, 2024, at 06:28, MOHAMMED Bahauddin N
 wrote:

I have a request related to the Keystore password in Apache
Tomcat's 'server.xml' file. Currently, the password under the
Connector port is displayed in plain text,



Displayed to whom?



which is a security concern.



No, it’s not - as long as you have properly secured the Tomcat
configuration files. They should be accessible only by the userid
Tomcat runs with and the Tomcat administrator (if using a different
userid). No other users should have any access.



I am looking to encrypt it through configuration (not through any
code).I have reviewed the information provided in the link below,
which mentions configuration tips, but I don't understand some of
these (apart from the XML encoding).

https://cwiki.apache.org/confluence/display/TOMCAT/Password



The point of the article is that attempting to encrypt the Tomcat
configuration entries is … pointless. There will have to be a
decryption key saved somewhere that Tomcat has access to; if any
other users have access to that key, you’ve just wasted a lot of time
and effort for no gain. Much more efficient to expend that effort in
securing the Tomcat files.


I had this conversation with someone a long time ago and their argument
at the time was basically against shoulder-surfing. "If the password is 
'hummingbird'" then someone can just read it and go write it down 
elsewhere."


Okay, sure. So just make your password random junk and that will solve 
the shoulder-surfing issue. All other use-cases are just making more 
work for everybody who already really has access to the password.


I make it a habit of generating secrets basically like this:

$ dd if=/dev/urandom bs=1024 count=10 | sha1sum

10k of random garbage into sha1sum gives me a nice big random blob every 
time. Copy, paste, done. Unless someone is able to take a photro over 
your shoulder, you are fine. If that happens, why are you letting them 
take pictures? Why are you letting them log into your application server 
to impersonate your application? So many "whys".


Choosing a non-trivial password and file-level permissions should be 
sufficient. Everything else is hand-waving.


I have become more interested in the ServiceBindingPropertySource class 
recently, but that has MUCH more to do with deployment flexibility than 
security. But the passwords aren't in server.xml anymore!


-chris

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

Re: Tomcat deploying war file for every restart on Red Hat Linux 8.6

2024-08-02 Thread Christopher Schultz


Channa,

On 8/2/24 05:30, Channa Puchakayala wrote:

Hi Tomcat Team,

Issue : Apache Tomcat deploying war file for every restart on Red Hat 
Linux 8.6 even though there are no changes in war file.


Observations:

-war-tracker file timestamp is setting with tomcat restart time which is 
not matched with original war file timestamp, so tomcat deleting 
existing ca-nim-sm folder and extracting war again for every restart.


-Tomcat log message is below

=

Line 13640: 2024-07-26 06:41:46,035 [main] INFO 
  org.apache.catalina.startup.ExpandWar - An expanded directory 
[/usr/Spectrum/tomcat/webapps/*ca-nim-sm*] was found with a last 
modified time that did not match the associated WAR. It will be deleted.




-server.xml setting (  unpackWARs="true" autoDeploy="false">)


-We observed this for multiple web applications (wars) on multiple 
systems, so it is not an issue single web application(war)


-Issue observed in Red Hat Linux 8.6, but same not occurring on windows 
box and Red Hat Linux 8.8, 8.9 and 8.10


Please notice *ca-nim-sm.war* file  time stamp

Please notice *war-tracker* file time stamp, which is set to tomcat 
restart time


Environment

Red Hat Linux 8.6

Java: OpenJDK 11.0.23 and 17.0.10

Tomcat :  9.0.87 and 9.0.91

Verified tomcat release notes and also tomcat defects in 
https://bz.apache.org/bugzilla/ , could 
not find any info/defect related to this.


Could you please help us,  why war-tracker file timestamp getting 
updated with tomcat restart time instead of keeping war file timestamp.


The code is fairly simple here in ExpandWar.java: the war-tracker file 
gets the last-modified date of the WAR file that was expanded, and 
shouldn't trigger a re-load after that unless either the WAR file or the 
war-tracker file's timestamps are modified.


Can you post the results of these commands?

$ stat /usr/Spectrum/tomcat/webapps/ca-nim-sm.war
$ stat /usr/Spectrum/tomcat/webapps/ca-nim-sm
$ stat /usr/Spectrum/tomcat/webapps/ca-nim-sm/META-INF/war-tracker

Please note that the log file shows the paths as being under 
/usr/Spectrum/tomcat/webapps/... while your screenshots show 
/usr/apache-tomcat-9.0.91/webapps/... are you sure you are looking in 
the right place(s) for these files and timestamps?


The next thing to do would be to add both timestamps to the log message 
to see what their values are. Perhaps revealing their values will give 
some insight into the root problem.


Are you able to compile your own Tomcat locally, or would you need a 
custom release artifact to try something like that?


-chris

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

Re: Problem starting Tomcat localhost

2024-08-01 Thread Christopher Schultz


Alan,

On 8/1/24 05:00, Alan Masters wrote:
I have configured apache-tomcat-9.0.91 to run as localhost:8080 on 
Windows 11.


Once I have executed the startup.bat, and open localhost:8080 and get:

    If you're seeing this, you've successfully installed Tomcat.
    Congratulations

However frequently when closing down with shutdown.bat and re-starting 
with startup.bat then opening localhost:8080 I get:



  HTTP Status 404 – Not Found





    *Type*Status Report

    *Message*The requested resource [/] is not available

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






  Apache Tomcat/9.0.91

After various attempts to shutdown / re-start I get some success, but 
this is quite frustrating and makes using it for testing purposes 
difficult.


Any suggestions would be welcome.


Do you have any applications deployed into Tomcat besides the 
unmodified, stock applications that ship with Tomcat?


Is there anything interesting in logs/catalina.out or similar log files?

-chris

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

Re: Reg: tomcat CPU spikes

2024-07-30 Thread Christopher Schultz


Mark,

On 7/29/24 05:37, Mark Thomas wrote:

On 26/07/2024 22:19, Jalaj Asher wrote:

Thanks Christopher.
But can we also consider allowing caching of different types as 
caching jar files is very valuable as that avoids jar scans real time 
when the production is under load .


But trying to cache static content, which can be cached separately on 
client end, or jsps which are compiled and cached in work folder don’t 
need to be loaded in memory as they force a significant increase in 
memory utilization.


Sounds like you need to provide a custom 
org.apache.catalina.WebResourceRoot$CacheStrategy implementation.


See https://tomcat.apache.org/tomcat-11.0-doc/config/resources.html 
towards the end of the page and 
https://tomcat.apache.org/tomcat-11.0-doc/api/org/apache/catalina/WebResourceRoot.CacheStrategy.html


Oh, that's interesting. So for example you could implement something 
like this:


@Override

public boolean noCache(String path) {
return !path.endsWith(".jar");
}

?

This would only cache JAR files (and case-sensitively I might add).

-chris


-Original Message-
From: Christopher Schultz 
Sent: Monday, July 22, 2024 12:35 PM
To: users@tomcat.apache.org
Subject: Re: Reg: tomcat CPU spikes

Attention! - This email has originated from an External Source outside 
of eClinicalWorks. Always use caution when opening attachments, 
clicking links, or when responding to this email. If you feel this is 
a phishing scam, please use the Phish Alert Report button in Outlook.



Jalaj,

On 7/19/24 14:28, Jalaj Asher wrote:

This is the warning message we get when cachingAllowed is not set to
false

org.apache.catalina.webresources.Cache.getResource Unable to add the 
resource at [/WEB-INF/classes/] to the cache for web application 
[/x] because there was insufficient free space available after 
evicting expired cache entries - consider increasing the maximum size 
of the cache.


Okay, I see it. Specifically, it is a WARN message which is usually 
not suppressed in a production configuration.


@markt @remm what do you think about making this another of those 
"WARN the first time, DEBUG thereafter" kinds of messages?


It seems like if a cache is full, the operator SHOULD get a 
notification, but if the cache is thrashing, printing an error a huge 
number of times doesn't seem like it's terribly helpful. It just fills 
the disk.


-chris


-Original Message-
From: Jalaj Asher
Sent: Tuesday, July 16, 2024 1:30 PM
To: Tomcat Users List 
Subject: RE: Reg: tomcat CPU spikes


space". Which was very quickly filling up our disk space as well as
increasing disk IO causing latency concerns.
1. Also interesting. Can you post one of those messages here? Was 
there a stack trace shown or just the warning?


  It is just the warning. No stack trace. I will work on 
recreating this since all our environments has this disabled.


2. Interesting. How much static content do you have? This seems like 
a good use-case for a reverse-proxy to handle your static    content 
for you.
We have not collated the complete size of it. But are reasons we 
cannot do that.


Also I was reviewing some older heap dumps and I could see that the 
jars are getting cached in tomcat even with cachingAllowed=false.


Also this is not a consistent issue once it happens it takes sometime 
for the stack to go away as well as post tomcat reboots the problem 
goes away with the same settings and we do see that the wars are 
getting deployed during tomcat startup as well.


Regards

Jalaj P Asher


-Original Message-
From: Christopher Schultz 
Sent: Tuesday, July 16, 2024 10:05 AM
To: users@tomcat.apache.org
Subject: Re: Reg: tomcat CPU spikes

Attention! - This email has originated from an External Source 
outside of eClinicalWorks. Always use caution when opening 
attachments, clicking links, or when responding to this email. If you 
feel this is a phishing scam, please use the Phish Alert Report 
button in Outlook.



Jalaj,

On 7/15/24 18:18, Jalaj Asher wrote:

We ran into 2 issues
1. We needed to allocate significant amount of -XMX  for heap space,
if we allowed caching, since increasing memory by a few hundred MB as
well was not enough.
Interesting. How much static content do you have? This seems like a 
good use-case for a reverse-proxy to handle your static content for you.



2. Also with the setting being  enabled, it generated logs stating
"could not add a resource  as there wasn’t enough
space". Which was very quickly filling up our disk space as well as
increasing disk IO causing latency concerns.
Also interesting. Can you post one of those messages here? Was there 
a stack trace shown or just the warning?


-chris


-Original Message-
From: Christopher Schultz 
Sent: Monday, July 15, 2024 4:19 PM
To: users@tomcat.apache.org
Subject: Re: Reg: tomcat CPU spikes

Attention! - This email has originated from an External Source 
outside

Re: Which is better: many concurrent requests or a deep backlog?

2024-07-30 Thread Christopher Schultz


To whom it may concern,

On 7/30/24 10:33, mw...@iu.edu wrote:

For various reasons I have Tomcat behind Apache HTTPD via
mod_proxy_ajp, and I'm looking for good ways to think about the proxy
connection pool.  I'm wondering if I should let HTTPD make as many
connections as it wants, or set a maximum pool size and let requests
wait in the proxy.  This is probably a complex issue and I want to be
sure I'm considering the right aspects.


From the user's perspective, I think it doesn't matter which choice you 
make.



I think I do want persistent proxy connections.


AJP expects to use persistent connections.

This seems to work well and it saves setup/teardown work.  So I have 
"ProxyPass...enablereuse=on" (which I think is default, but I hate 
relying on defaults for things I care about).


Tomcat v9.0.90, HTTPD 2.4.62.  There are no obvious problems at the
moment.  I just want to be sure I'm doing all I can to keep this
back-end service from ever being a bottleneck for a rather heavy
Angular Universal front-end that has throughput issues of its own,
while I (and many others) ponder how to fix *those* issues.


No matter which strategy you choose, I suspect the bottleneck will 
always be the same thing: your application (or some proxy thereof, such 
as a database, back-end API, etc.).


Do you really care if connections are queuing-up in httpd versus Tomcat? 
One could argue that it's slightly less wasteful to have them queue-up 
on the httpd side but not really in terms of actual resource usage.


-chris

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

Re: how to use provider with java 18 , différent from java 11

2024-07-30 Thread Christopher Schultz


Aughra,

On 7/27/24 10:32, aughra wrote:

Hello everyone,

Maybe this question has been asked many times, but I have a problem that 
I can't find a solution for,.


To summarize, I have: A Java program WAR on Tomcat, and Tomcat must 
contain a provider to call an encryption module to obtain keys.


The Tomcat version is 10.1.26

In Java 11, to specify where the pass/crt of the module is located, I 
specify it in the java.security file as follows:


properties

Copier le code

#

# List of providers and their preference orders (see above):

#

security.provider.1=SUN

security.provider.2=SunRsaSign

security.provider.3=SunEC

security.provider.4=SunJSSE

security.provider.5=SunJCE

security.provider.6=SunJGSS

security.provider.7=SunSASL

security.provider.8=XMLDSig

security.provider.9=SunPCSC

security.provider.10=JdkLDAP

security.provider.11=JdkSASL

security.provider.12=SunPKCS11 
/opt/tomcat/webapps/prgmwar/WEB-INF/classes/Crypto.properties


The Crypto.propertiesfile contains the name of the provider to use and 
the library to call the Sun PKCS#11 provider:


library=lib.so

name=cryptto

Which is used in the application parameter (SunPKCS11 is normal, WL, and 
the documentation states it):


module.titi.providerName=SunPKCS11-cryptto

However, it is clearly stated that in Java 17, this solution is no 
longer supported, and it must be done differently; otherwise, I get 
errors in Catalina.


It is stated not to put the path in the java.securityfile and to leave:

security.provider.12=SunPKCS11

I have tried several solutions, putting the path in setenv, in 
catalina.shwith the option:


JAVA_OPTS="$JAVA_OPTS -Djava.security.properties=file:/toto.file"

CATALINA_OPTS="$CATALINA_OPTS -Djava.security.properties=file:/toto.file"

With the file containing the path: toto.file:

security.provider.12=SunPKCS11 
/opt/tomcat/webapps/prgmwar/WEB-INF/classes/Crypto.properties


Almost everywhere I could put it.

But in catalina.out, I still get the same error with Tomcat:

/opt/tomcat/webapps/prgmwar/WEB-INF/classes/appli.properties-> it loads 
the application


HSM-SERVICE|WARN|http-nio-8080-exec-1||GET 
appli||SecurityModuleFactory|Module appli ignored: error during 
initialization


When it searches for the provider, it can't find it because it doesn't 
have: security.provider.12= SunPKCS11 
/opt/tomcat/webapps/prgmwar/WEB-INF/classes/Crypto.propertiesProvider 
"SunPKCS11-crypt" unknown


However, it works very well in a normal Java JAR (without Tomcat), for 
example, to list the keys, because I directly list the provider's 
location via the -Doption of Java:


DEBUG [main] (SecurityModuleFactory.java:112) - Loading crypt module.

DEBUG [main] (SecurityModuleFactory.java:125) - -> SunPKCS11-crypt

Security.java:125)

DEBUG [main] (SecurityModule.java:59) - Creating HardwareSecurityModule 
crypt


crypt - Beginning listKeys

(SecurityModule.java:121) - name = riri

So my library works...

*My question is, how do we do in Java 17 what I did in Java 8 in : 
java.security:*


*security.provider.12=SunPKCS11 
/opt/tomcat/webapps/prgmwar/WEB-INF/classes/Crypto.properties***


Please don't look for any flaws in the variable names as I have just 
changed them.


How are you launching Tomcat?

Setting CATALINA_OPTS in setenv.sh is, I believe, the correct way to do 
this, but it depends upon how Tomcat is launched. Some environments 
ignore the setenv.sh script.


Can you use 'ps' or similar to see the full command-line used to launch 
the JVM and confirm your -D appears there? If it's not there, you have 
made a small mistake somewhere or Tomcat isn't being started using 
catalina.sh.


-chris

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

Re: Issue with the log4j2.xml

2024-07-26 Thread Christopher Schultz


Saicharan,

On 7/26/24 09:36, Burle, Saicharan wrote:

We are observing a strange behavior for our app running on the Tomcat9.

Issue:
We have 2 applications configured on tomcat9 (Java8) named app1 & app2. There are 2 log 
files named a.log & b.log to be created under a path /a/b/c (for app1) & /d/e/f (for 
app2) and this path is defined in log4j2.xml. The log files a.log & b.log is getting 
created at /a/b/c for app1 but not for app2 and instead it is getting written in default 
Catalina.out file. Nothing created under /d/e/f.


Where is log4j2.xml located?

Where is log4j2-*.jar located?

How does each application initialize log4j2?


We tried few steps in our lab server and below are our observations.


   1.  Got this issue when we are Migrating from RHEL-7 to RHEL-8


Which of the following changed during this migration?

- Java version
- Tomcat version
- Application version/configuration/etc


   2.  The same war file for app1 and app2 is working as expected in RHEL-7 
(a.log and b.log getting created under the path /a/b/c and d/e/f respectively).
   3.  No Issue on RHEL-8, When the war is built locally (created from same 
branch where Prod war file is) and deployed MANUALLY.
   4.  We got ISSUE on RHEL-8, when the war is built and deployed via UCD.
   5.  No issues in RHEL-7 with UCD build and deploy.

So, we are not sure if it is RHEL-8 or the UCD that is causing this issue. 
Could you please take a look at it and help with steps to resolve this issue.

>

Please let me know in case you need further information.


What is UCD?

If things run under both RHEL-7 and RHEL-8 when building locally, I 
would guess that something is wrong with either (a) the data transfer 
mechanism or (b) the configuration of the target environment, and the 
data-transfer is not relevant.


I would focus on the environmental changes. Look for what files are 
where (under the Tomcat deployment, including Tomcat configuration files 
and libraries), and the differences between the working-environment and 
the non-working environment.


-chris

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

Re: Tomcat 9.0.80 Server Issues.

2024-07-26 Thread Christopher Schultz


Venkat,

On 7/26/24 08:06, Venkateswararao Dama wrote:

Even Tomcat 9.0.91 version with JDK 17 and application running on
Windows 2022 server has same caching issues

Okay.


in 9.0.91 version of Tomcat Callback handlers are working as it
expected in JAAS authentication according to Tomcat 9.0.91 change
log, is this true
Is that a question or a statement? Are you saying that JAAS *is* 
working, or *is not* working?



in Tomcat 9.0.91 why response headers are in Private mode instead of
expiring Jan 1st 1970, shall I adjust response headers to private
mode, max-expires to 6000.
Is this related to JAAS, or unrelated? It's best to handle one issue at 
a time. So if the HTTP response headers are the biggest problem for you, 
let's start there. If something else is more important, let's deal with 
that, first.


So what's your biggest issue?


How to handle response headers in my Spring MVC application from
expire mode to private, even though I am using expires zero, whey it
is ignoring, what tag I need to use to get back to backward
compatibility in my Spring MVC application not caching from browsers,
JAAS authetification validates User Name/Password properly from
Tomcat container. Please help me here when you get a chance, your
help here mostly appreciated.
What behavior are you expecting (specifically)? What behavior are you 
seeing?


What other differences do you have between your working environment and 
your non-working environment?


For example, if you are using TLS in your working production environment 
but your non-working testing environment has no TLS, that's important 
information to have.


-chris

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

Re: Tomcat 9.0.80 Server Issues.

2024-07-26 Thread Christopher Schultz


Chuck and Venkat,

On 7/25/24 22:48, Chuck Caldarale wrote:

On Jul 25, 2024, at 20:45, venkatd...@hotmail.com Shanthisowjanyadama9 
 wrote:

>>
I am also wondering why backward compatibility is not maintained 
in Tomcat Server end when I switch from one version of Tomcat to

another version.


Compatibility is maintained, except when relevant standards are being
violated, especially when related to security. In some such cases,
the old, invalid behavior can be re-enabled with configuration tags.
Check the Tomcat 9.0 documentation to see if anything might be useful
in your case.

Most “compatibility” problems are actually application bugs, such as
hanging onto references to response or request objects after a
response has been committed.

+1

I have an application originally built for Tomcat 4.something that has 
never had any compatibility issues between then and Tomcat 9.


I've even recently been deploying it on Tomcat 10.1 and allowing Tomcat 
to "migrate" the entire application to Jakarta EE APIs and it runs 
flawlessly.


Any apparent incompatibilities are likely to fall in one of several 
categories:


1. Use of Servlet Spec features, etc. that have been deprecated
   and should not be used. The fix here is to write standards-compliant
   applications using the current specifications and the nuances
   thereof. For example, some APIs are still present but should never
   be used (e.g. SingleThreadServlet or whatever, or getRealPath).

2. Significant non-standard configuration, usually trying to work-around
   some abuse of one or more specifications. If you are tweaking the
   handling of URI characters, slash processing, etc. then it's time
   to fix your application so that it doesn't rely on those risky
   configurations.

3. Use of Tomcat-specific APIs, internals, or libraries. Just don't
   do this. You don't want to be locked-in to any specific vendor, do
   you? I avoid vendor lock-in, even if the "vendor" is ASF.

-chris

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

Re: java code cache size question

2024-07-25 Thread Christopher Schultz


Ivano,

On 7/25/24 09:43, Ivano Luberti wrote:
Hi, I have a tomcat 9 instance  that runs without specifying options for 
the code cache.


Good. If you don't know what you are doing, leaving options at their 
defaults is the best policy.



Looking at the servet status I see

Code Cache Non-heap memory 2.43 MiB 163.93 MiB 240.00 
MiB 147.30 MiB (61%)


This is difficult to read. Can you re-format it to make it more readable?


So the maximum size is 240MB

Looking at Java documentation it states it should be 48MB if not altered 
by options.


What documentation? What version of Java? What operating system? How 
much total main memory? Are you *sure* there are no options being 
specified on the command-line? Try looking at the effective command-line 
provided by the operating system and not just at the script that you run 
yourself.


Is there someone able to suggest if tomcat can override autonomously the 
default?


This is far to low of a detail for Tomcat to care about.


We start tomcat usinf tomcat.service file


There are no systemd service files provided by the Tomcat project. You 
may have to consult your package vendor for more details.


-chris

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

Re: Problems with the most problematic of our Tomcat installations on IBM Midrange (cross-posted to Midrange and Tomcat Lists)

2024-07-24 Thread Christopher Schultz


James,

On 7/24/24 18:07, James H. H. Lampert wrote:
So what jobs are in the subsystem? You said "the Catalina job and its 
associated JVM job" but to me those are just a single job/process. Are 
they separate things in the IBM world?


Thanks for your insights, Mr. Schultz. And yours, too, Herr Hoffmann.

On an IBM Midrange box (AS/400, iSeries, whatever IBM is calling it this 
week), when a shell script (a non-native construct in the IBM Midrange 
world - the native equivalent is something called a CL program, which is 
a compiled object) spawns off a JVM process, it shows up as a separate 
job, typically with the rather cryptic name QP0ZSPWT.


As I recall, when we first started using Tomcat (6, I think!) on IBM 
Midrange boxes, the Catalina job would terminate after spawning off the 
JVM job. Or if you called catalina.sh from a terminal session, you'd get 
your command line back. This changed with (I think) Tomcat 7.


At any rate, that's literally all that's in the dedicated subsystem 
(which is fairly easy to set up on an IBM Midrange box; just create a 
subsystem description, with a private memory pool, if desired, give it a 
routing entry and a job queue, do a STRSBS on it, and you've got your 
subsystem, along with a way to send jobs into it).


At any rate, we don't currently have any dumps on that particular 
customer box, because unless we're planning on having dumps analyzed, 
they're just wasting disk on a box that is not exactly hip-deep in 
unused mass storage. Hopefully, the next time this happens, it will 
happen at a time when our webapp developers aren't hip-deep in other 
projects (famous last words).


If you have access to the box, you can trigger a heap dump yourself 
anytime you want. You will need enough disk space for the dump, so if 
you have a 5ish GiB heap, be prepared for a big ole' file.


Then you can present it to your dev team when they are ready :)

You can also configure the JVM to dump the heap on OOME which it sounds 
like you already have. It you have one or two of them laying around, you 
should look at them. :)


-chris

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

Re: Problems with the most problematic of our Tomcat installations on IBM Midrange (cross-posted to Midrange and Tomcat Lists)

2024-07-24 Thread Christopher Schultz


James,

On 7/23/24 16:54, James H. H. Lampert wrote:

On 7/23/24 1:25 PM, Christopher Schultz wrote:

Thomas,


Uh, "James." Thomas was someone who answered earlier.


:|

2. What has to fit into that 7GiB private memory pool? Does it include 
any OS, or is it just the JVM itself?


On an IBM Midrange box, a private memory pool simply provides jobs in a 
given subsystem with memory that's off-limits to jobs outside that 
subsystem. If the subsystem description's memory pool usage is set up 
correctly, it will grab memory from its private pool whenever possible, 
before going to the public "base" memory pool on the system. This 
reduces the number of page faults.


Okay.

So what jobs are in the subsystem? You said "the Catalina job and its 
associated JVM job" but to me those are just a single job/process. Are 
they separate things in the IBM world?


And based on the back-end server jobs, there are, at last count, 58 
users currently signed on, each one with a dedicated connection to a 
back-end server job. (The webapp is itself a client to a back-end server 
that was originally designed for a desktop Java client.)


That doesn't sound like a lot of users. Will it grow and ultimately fail 
with zero users? How about just one? If you really load it down, will it 
fail faster?


Do you have any kind of memory monitoring of the JVM process going on, 
or do you just have the heap-dump-on-oome configured?


The heap dump will tell your developers A LOT. Any decent heap-dump 
analyzer will be able to tell you what's taking up all the memory pretty 
quickly. Any time I've ever helped anyone look at a Java heap problem, 
one of the following checks always points directly to the problem:


1. One object (and tree of references) that is particularly large.
or
2. One kind of object for which there are a HUGE number of instances.

Sometimes there is a lot of overlap between these two.

When you load the heap dump, you'll notice that there are a huge number 
of char[], byte[], and String instances. Don't panic (yet). That's 
totally normal.


Even VisualVM can read heap dumps and give you some good information. 
Try looking for "Dominators".


-chris

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

Re: Problems with the most problematic of our Tomcat installations on IBM Midrange (cross-posted to Midrange and Tomcat Lists)

2024-07-23 Thread Christopher Schultz


Thomas,

On 7/23/24 13:44, James H. H. Lampert wrote:

Ladies and Gentlemen:

We still have a chronic Tomcat crashing problem at one of our 
installations.


The weirdest thing about this is that while this is certainly *one* of 
our heaviest-usage installations, it's not *the* heaviest.


We already have Tomcat shutting down and restarting itself every night. 
And we have the Catalina job and its associated JVM job running in a 
private subsystem, with a 7G private memory pool before it starts to dip 
into the base memory pool. And we're launching with (according to 
catalina.out) -Xms4096m Xmx5120m.


Might I make a few recommendations and comments, here?

1. Don't bother setting the min and max heap sizes different from each 
other. Assuming the process is going to grow to the max heap, you're 
going to need the max anyway so you may as well allocate it all at once 
up front.


2. What has to fit into that 7GiB private memory pool? Does it include 
any OS, or is it just the JVM itself?


3. Note that JVM memory requirements aren't limited to the heap. There's 
plenty of "native memory" that is necessary to run a JVM as well. For 
example, I have a production application with heap settings -Xms2048M 
-Xmx2048M and 'ps' tells me that the virtual size of the process is 
9.9GiB and the resident size is 2.7GiB. With a ~5GiB heap, you run the 
risk of hitting your memory limit. If you are getting "OOME heap" then 
this is not your issue, but it's something to think about.


Our webapp has integration with M$ Office 365, which this installation 
uses.


The usual pattern when it starts to get into trouble may be connected 
with that integration. Looking at a typical crash in catalina.out, I see 
several OAuth2 errors that appear to involve an expired token, producing 
lengthy (over 50 line) Java stacktraces.


Other errors seem to involve messages from graph.microsoft.com involving 
"item not found," that seem to be connected with email attachment 
downloads from Office365.


Then a NullPointerException is thrown, producing a stacktrace of over 60 
lines.


Long stack traces are not uncommon in web-based applications, especially 
if an application framework is involved and/or if you have many 
"forward" operations where a request gets forwarded through several 
components before a response is finally generated.


I wouldn't draw too many conclusions from the stack-trace size(s).


Then another Microsoft "item not found," like the previous one.

Then a handshaking error. Not sure what the handshaking error is *with.*

Then Tomcat runs out of memory in the Java heap space, does a dump, and 
everything hits the proverbial fan. 4775 lines of catalina.out entries 
before we manually shut it down with extreme prejudice and restart it, 
508 of them before the first out-of-memory error, the rest after.


And yes, I've packaged up an excerpt to send to our webapp developers, 
to see if they can make head or tail of what went wrong.


Anybody have any suggestions of what to look for?


As Thomas suggested, a heap dump would be helpful but if you have 
already provided that to your application developers there is no need to 
send it to us. But... if they aren't sure how to read it or aren't sure 
what it's telling them... perhaps you should send THEM to *us*.


It's helpful to know some more about the application. How many users do 
you typically serve at a time (concurrent logins, not necessarily 
concurrent requests)? What kind of information gets stored long-term in 
the application's heap? This would be things such as session storage 
(per user, should be freed on logout) or caches (typically global, 
either never freed or some kind of eviction policy like "last 1000 
entries"). Sometimes, the application really is just storing too much in 
memory.


I had an application that ran for years very happily with 64MiB of heap. 
One day it started throwing OOMEs and when we investigated the cause, it 
turns out we just had more users than we had in the past and we simply 
needed to resize of heap.


(A much later analysis showed that handing much more heap to the memory 
manager made the GC run a lot more efficiently and "stole" less time 
away from the application over time. So we run with a 2GiB heap now, 
even though we don't need nearly that much operating memory.)


-chris

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

Re: Reg: tomcat CPU spikes

2024-07-23 Thread Christopher Schultz


Mark,

On 7/23/24 03:36, Mark Thomas wrote:

On 22/07/2024 17:35, Christopher Schultz wrote:

Jalaj,

On 7/19/24 14:28, Jalaj Asher wrote:
This is the warning message we get when cachingAllowed is not set to 
false


org.apache.catalina.webresources.Cache.getResource Unable to add the 
resource at [/WEB-INF/classes/] to the cache for web application 
[/x] because there was insufficient free space available after 
evicting expired cache entries - consider increasing the maximum size 
of the cache.


Okay, I see it. Specifically, it is a WARN message which is usually 
not suppressed in a production configuration.


@markt @remm what do you think about making this another of those 
"WARN the first time, DEBUG thereafter" kinds of messages?


It seems like if a cache is full, the operator SHOULD get a 
notification, but if the cache is thrashing, printing an error a huge 
number of times doesn't seem like it's terribly helpful. It just fills 
the disk.


I'm not sure. If this happens occasionally, then an occasional message 
seems reasonable. If the cache is thrashing then that is bad and a slew 
of log messages highlighting that doesn't seem unreasonable.


Is there a valid case where you would want the cache to thrash?


Good question.

I could imagine an operator setting a cache size and it's okay if there 
is turnover within the cache, but actual thrashing is not great.


If I am running a web site and I have 1M static documents but only 500 
classes or whatever, I might only want to cache those classes and other 
resources (e.g. properties files) but not the huge bulk of static 
content, especially if the files are large.


Thanks,
-chris


-Original Message-
From: Jalaj Asher
Sent: Tuesday, July 16, 2024 1:30 PM
To: Tomcat Users List 
Subject: RE: Reg: tomcat CPU spikes


space". Which was very quickly filling up our disk space as well as
increasing disk IO causing latency concerns.
1. Also interesting. Can you post one of those messages here? Was 
there a stack trace shown or just the warning?


 It is just the warning. No stack trace. I will work on 
recreating this since all our environments has this disabled.


2. Interesting. How much static content do you have? This seems like 
a good use-case for a reverse-proxy to handle your static    content 
for you.
We have not collated the complete size of it. But are reasons we 
cannot do that.


Also I was reviewing some older heap dumps and I could see that the 
jars are getting cached in tomcat even with cachingAllowed=false.


Also this is not a consistent issue once it happens it takes sometime 
for the stack to go away as well as post tomcat reboots the problem 
goes away with the same settings and we do see that the wars are 
getting deployed during tomcat startup as well.


Regards

Jalaj P Asher


-Original Message-
From: Christopher Schultz 
Sent: Tuesday, July 16, 2024 10:05 AM
To: users@tomcat.apache.org
Subject: Re: Reg: tomcat CPU spikes

Attention! - This email has originated from an External Source 
outside of eClinicalWorks. Always use caution when opening 
attachments, clicking links, or when responding to this email. If you 
feel this is a phishing scam, please use the Phish Alert Report 
button in Outlook.



Jalaj,

On 7/15/24 18:18, Jalaj Asher wrote:

We ran into 2 issues
1. We needed to allocate significant amount of -XMX  for heap space,
if we allowed caching, since increasing memory by a few hundred MB as
well was not enough.
Interesting. How much static content do you have? This seems like a 
good use-case for a reverse-proxy to handle your static content for you.



2. Also with the setting being  enabled, it generated logs stating
"could not add a resource  as there wasn’t enough
space". Which was very quickly filling up our disk space as well as
increasing disk IO causing latency concerns.
Also interesting. Can you post one of those messages here? Was there 
a stack trace shown or just the warning?


-chris


-Original Message-
From: Christopher Schultz 
Sent: Monday, July 15, 2024 4:19 PM
To: users@tomcat.apache.org
Subject: Re: Reg: tomcat CPU spikes

Attention! - This email has originated from an External Source 
outside of eClinicalWorks. Always use caution when opening 
attachments, clicking links, or when responding to this email. If 
you feel this is a phishing scam, please use the Phish Alert Report 
button in Outlook.



Jalaj,

On 7/15/24 15:03, Jalaj Asher wrote:

Yeah I was wondering the same as this has been in place since a few
years now atleast 4 years since cachingAllowed had some changes in
tomcat 8 which was resulting in it caching all static content as well
as jsps and jars and our though process was if we have static content
being cached on the client end and jsps in the work folder each time
on access we don’t need the cache.

Does the cache actively hurt you?

Is there a way to cache just the jars and not every thing e

Re: Intermittent Missing Content-Type

2024-07-22 Thread Christopher Schultz


Simon,

On 7/18/24 14:54, Simon Arame wrote:

Greetings folks,

According to JavaServer Pages™ specs v2.3 #JSP4.2, when a JSP page does not
provide the TYPE value of the contentType attribute, "the initial content
type is “text/html” for JSP pages in standard syntax"

With our relatively big web application, we are experiencing an
intermittent issue which is a missing Content-Type header on some JSP pages
and the issue goes away when we use 9.0.90+ or set
org.apache.catalina.connector.RECYCLE_FACADES to true.


This is likely because the default for that setting changed in 9.0.90 
from "false" to "true":


https://tomcat.apache.org/tomcat-9.0-doc/changelog.html#Tomcat_9.0.90_(remm)

If the issue goes away when discarding facades, my first response would 
be to suggest that there is an issue in the application which is 
retaining a reference to a response object and damaging that content-type.


It's also possible that there is a subtle bug in Tomcat where the 
content-type isn't being reset as expected.



Some of our clients are not easily updating their tomcat version so I would
like to know what we are doing wrong maybe in our custom Filter that causes
the occasional missing content-type when facades are not recycled.


It may be very difficult to track-down the source of this issue. If you 
are able to provide a simple JSP that behaves in this way and perhaps a 
Filter that sometimes causes an issue, we may be able to help track it 
down. But if you can't share code, we can't help.


It may be better for you to simply reconfigure your clients to disable 
facade reuse either by using the RECYCLE_FACADES=true system property or 
to use the discardFacades="true"  attribute which has been in 
Tomcat 9.0.x since 9.0.31:


https://tomcat.apache.org/tomcat-9.0-doc/changelog.html#Tomcat_9.0.31_(markt)


I got help from Konstantin Kolinko to locate some historical tomcat code
changes. What I was trying to determine is details about the "recycle"
method of the Request implementation and with Konstantin's help (see
below), I make the reconciliation with the CoyoteRequest and the
CoyoteRequestFacade classes. Now I can see the commit 301781 simply adds
those. Is this coming straight on from a CVS repository ? If yes, can the
CVS repository archive can still be publicly accessed ? At this point, I am
not sure if commit 302827 (
https://svn.apache.org/viewvc?view=revision&revision=302827 ) would explain
what i was searching for. My point is that at 301781 (
https://svn.apache.org/viewvc?view=revision&revision=301781 ), the facade
is only cleared if Constants.SECURITY is true and now since 9.0.90, facades
are cleared by default unless you change the option
org.apache.catalina.connector.RECYCLE_FACADES to false.


The facade is always "cleared" in one way or the other. When the facade 
will be re-used (aka "recycled"), the information that had previously 
been in the facade needs to be "cleared" by nulling-out references and 
setting primitive fields back to their defaults.


If the facade will be discarded and a new object created in its place, 
there is no reason to explicitly "clear" the old object... Tomcat simply 
lets the reference go out of scope and the GC will clean it up at some 
point. So when the facade will be GC'd, we don't bother blanking-out all 
those fields.



So following that logic, I found out what facade recycling was but I don't
know why we rely on it.


This is a performance optimization that IMHO is mostly historical at 
this point. Requests ought to be fast enough that the cycle of request 
-> new object -> end request -> GC should be very cheap as most requests 
will not "survive" a minor GC action. The effects of "new/malloc" and 
(conceptually) delete/free are essentially zero with modern Java memory 
managers for short-lived objects.



The missing content-type occurs when we navigate quickly between jsp pages.

Here are some of the actions we performed in our custom Filter,
1. we are conditionally setting some headers on the Response object.


Where does this happen? In the doFilter method, or elsewhere? If you are 
not retaining any references to the response (or request, for that 
matter) after doFilter ends, then this issue shouldn't be "your fault". 
But if you are stashing references to the HttpServletRequest or 
HttpServletResponse into the request, response, session, some 
object-level or class-level member, etc. then you might be causing this 
problem yourself.



2. we are conditionally calling the RequestDispatcher.include method to add
a JSP head ( stuffs like  )


This sounds like a job for a view-framework, but should have nothing to 
do with the behavior you are describing.



3. depending on an external authentication call result we are either
sending a redirect or calling FilterChain.doFilter


Sounds okay to me so far.


Please note that we tried the following without success:
- declaring a default-content-type inside a jsp-property-group as
prescribed by the JavaServer

Re: Reg: tomcat CPU spikes

2024-07-22 Thread Christopher Schultz


Jalaj,

On 7/19/24 14:28, Jalaj Asher wrote:

This is the warning message we get when cachingAllowed is not set to false

org.apache.catalina.webresources.Cache.getResource Unable to add the resource 
at [/WEB-INF/classes/] to the cache for web application [/x] because there 
was insufficient free space available after evicting expired cache entries - 
consider increasing the maximum size of the cache.


Okay, I see it. Specifically, it is a WARN message which is usually not 
suppressed in a production configuration.


@markt @remm what do you think about making this another of those "WARN 
the first time, DEBUG thereafter" kinds of messages?


It seems like if a cache is full, the operator SHOULD get a 
notification, but if the cache is thrashing, printing an error a huge 
number of times doesn't seem like it's terribly helpful. It just fills 
the disk.


-chris


-Original Message-
From: Jalaj Asher
Sent: Tuesday, July 16, 2024 1:30 PM
To: Tomcat Users List 
Subject: RE: Reg: tomcat CPU spikes


space". Which was very quickly filling up our disk space as well as
increasing disk IO causing latency concerns.

1. Also interesting. Can you post one of those messages here? Was there a stack 
trace shown or just the warning?

 It is just the warning. No stack trace. I will work on recreating this 
since all our environments has this disabled.

2. Interesting. How much static content do you have? This seems like a good 
use-case for a reverse-proxy to handle your staticcontent for you.
We have not collated the complete size of it. But are reasons we cannot do that.

Also I was reviewing some older heap dumps and I could see that the jars are 
getting cached in tomcat even with cachingAllowed=false.

Also this is not a consistent issue once it happens it takes sometime for the 
stack to go away as well as post tomcat reboots the problem goes away with the 
same settings and we do see that the wars are getting deployed during tomcat 
startup as well.

Regards

Jalaj P Asher


-Original Message-
From: Christopher Schultz 
Sent: Tuesday, July 16, 2024 10:05 AM
To: users@tomcat.apache.org
Subject: Re: Reg: tomcat CPU spikes

Attention! - This email has originated from an External Source outside of 
eClinicalWorks. Always use caution when opening attachments, clicking links, or 
when responding to this email. If you feel this is a phishing scam, please use 
the Phish Alert Report button in Outlook.


Jalaj,

On 7/15/24 18:18, Jalaj Asher wrote:

We ran into 2 issues
1. We needed to allocate significant amount of -XMX  for heap space,
if we allowed caching, since increasing memory by a few hundred MB as
well was not enough.

Interesting. How much static content do you have? This seems like a good 
use-case for a reverse-proxy to handle your static content for you.


2. Also with the setting being  enabled, it generated logs stating
"could not add a resource  as there wasn’t enough
space". Which was very quickly filling up our disk space as well as
increasing disk IO causing latency concerns.

Also interesting. Can you post one of those messages here? Was there a stack 
trace shown or just the warning?

-chris


-Original Message-
From: Christopher Schultz 
Sent: Monday, July 15, 2024 4:19 PM
To: users@tomcat.apache.org
Subject: Re: Reg: tomcat CPU spikes

Attention! - This email has originated from an External Source outside of 
eClinicalWorks. Always use caution when opening attachments, clicking links, or 
when responding to this email. If you feel this is a phishing scam, please use 
the Phish Alert Report button in Outlook.


Jalaj,

On 7/15/24 15:03, Jalaj Asher wrote:

Yeah I was wondering the same as this has been in place since a few
years now atleast 4 years since cachingAllowed had some changes in
tomcat 8 which was resulting in it caching all static content as well
as jsps and jars and our though process was if we have static content
being cached on the client end and jsps in the work folder each time
on access we don’t need the cache.

Does the cache actively hurt you?


Is there a way to cache just the jars and not every thing else in memory ?


I think the short answer is "no there is not a way to do this" but I may be 
wrong.

The long answer might be "maybe, but you will have to play games with  
and  and maybe some other things to get it working.

I would save yourself some complexity and simply enable caching.

-chris


-Original Message-
From: Christopher Schultz 
Sent: Friday, July 12, 2024 4:02 PM
To: users@tomcat.apache.org
Subject: Re: Reg: tomcat CPU spikes

Attention! - This email has originated from an External Source outside of 
eClinicalWorks. Always use caution when opening attachments, clicking links, or 
when responding to this email. If you feel this is a phishing scam, please use 
the Phish Alert Report button in Outlook.


Jalaj,

On 7/12/24 10:19, Jalaj Asher wrote:

Thank you Chuck and J

Re: Issue with JDK 11 and tomcat-embed-core 9.0.91

2024-07-18 Thread Christopher Schultz


Greg,

On 7/15/24 5:01 PM, Greg Eschbacher wrote:

Hi all,

I'm hoping you all can help me:  Our JDK 11 application uses tomcat-embed-core, 
and we're upgrading from 9.0.88 to 9.0.91 and we can no longer compile.

After some investigation, I believe the issue is that the tomcat-embed-core jar 
file no longer contains a module-info.class file.   When I unzip the jar for 
9.0.88 and 9.0.90, those jars contain module-info.class right in the root.  
However, 9.0.91 does not.

The symptom when compiling is this message:  module not found: 
org.apache.tomcat.embed.core   requires org.apache.tomcat.embed.core;

You can see this by comparing:  
https://repo1.maven.org/maven2/org/apache/tomcat/embed/tomcat-embed-core/9.0.91/tomcat-embed-core-9.0.91.jar
  to 
https://repo1.maven.org/maven2/org/apache/tomcat/embed/tomcat-embed-core/9.0.90/tomcat-embed-core-9.0.90.jar

I spot-checked a few more (9.0.84, and 9.0.88) and they all had 
module-info.class in the zip.


Is this change an intentional design change, or perhaps just a mistake?


This looks like a packaging mistake. I see a Bugzilla issue for it and I 
believe it will be fixed for the next releases (likely in early August).


-chris

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

Re: Reg: tomcat CPU spikes

2024-07-16 Thread Christopher Schultz


Jalaj,

On 7/15/24 18:18, Jalaj Asher wrote:

We ran into 2 issues
1. We needed to allocate significant amount of -XMX  for heap space,
if we allowed caching, since increasing memory by a few hundred MB as
well was not enough.
Interesting. How much static content do you have? This seems like a good 
use-case for a reverse-proxy to handle your static content for you.



2. Also with the setting being  enabled, it generated logs stating
"could not add a resource  as there wasn’t enough
space". Which was very quickly filling up our disk space as well as
increasing disk IO causing latency concerns.
Also interesting. Can you post one of those messages here? Was there a 
stack trace shown or just the warning?


-chris


-Original Message-----
From: Christopher Schultz 
Sent: Monday, July 15, 2024 4:19 PM
To: users@tomcat.apache.org
Subject: Re: Reg: tomcat CPU spikes

Attention! - This email has originated from an External Source outside of 
eClinicalWorks. Always use caution when opening attachments, clicking links, or 
when responding to this email. If you feel this is a phishing scam, please use 
the Phish Alert Report button in Outlook.


Jalaj,

On 7/15/24 15:03, Jalaj Asher wrote:

Yeah I was wondering the same as this has been in place since a few
years now atleast 4 years since cachingAllowed had some changes in
tomcat 8 which was resulting in it caching all static content as well
as jsps and jars and our though process was if we have static content
being cached on the client end and jsps in the work folder each time
on access we don’t need the cache.

Does the cache actively hurt you?


Is there a way to cache just the jars and not every thing else in memory ?


I think the short answer is "no there is not a way to do this" but I may be 
wrong.

The long answer might be "maybe, but you will have to play games with  
and  and maybe some other things to get it working.

I would save yourself some complexity and simply enable caching.

-chris


-Original Message-
From: Christopher Schultz 
Sent: Friday, July 12, 2024 4:02 PM
To: users@tomcat.apache.org
Subject: Re: Reg: tomcat CPU spikes

Attention! - This email has originated from an External Source outside of 
eClinicalWorks. Always use caution when opening attachments, clicking links, or 
when responding to this email. If you feel this is a phishing scam, please use 
the Phish Alert Report button in Outlook.


Jalaj,

On 7/12/24 10:19, Jalaj Asher wrote:

Thank you Chuck and John for the responses.

Just a few points from the things you highlighted and wanted me to
check 1. unpackwar is set to true. I checked and was informed that we need
 that to be true for a specific war file.
2. cachingAllowed=false. We keep it as false across the board.


Well... that'll do it. In order to locate resources, Tomcat needs to sift 
through all of those JAR files every time. Scanning ZIP files is expensive.

You might want to reconsider this particular setting in your environment.


Also the reason I shared 2 different stacks is to highlight that the
problem does not occur post restart or with any specific part of the
application like the parser going in a loop but it kicks of at random
times impacting multiple tomcats. But all having the same stack
waiting on archiveresourceset and java.util.zip.

My only question would be "why is this only now coming to your attention? 
Things should have been behaving this way .. for a long time.


I am working on getting both types of stacks to share here as well.

Had a question we just have one war file if unpack war is triggered
why should it impact loading jars from the entire webapp lib ?


Because WEB-INF/lib is full of JAR files that need to be scanned every tie you 
try to load ... anything. Since you have disabled caching, it has to re-check 
every file for every resource-load request.

-chris


-Original Message-
From: Chuck Caldarale 
Sent: Wednesday, July 10, 2024 6:19 PM
To: Tomcat Users List 
Subject: Re: Reg: tomcat CPU spikes

Attention! - This email has originated from an External Source outside of 
eClinicalWorks. Always use caution when opening attachments, clicking links, or 
when responding to this email. If you feel this is a phishing scam, please use 
the Phish Alert Report button in Outlook.



On Jul 10, 2024, at 17:02, Jalaj Asher  
wrote:

Sharing another stack to see if this can give any more insights.this thread is 
the tomcat main thread was loading about 65MB of data.

"main" #1 prio=5 os_prio=0
 java.lang.Thread.State: RUNNABLE
at java.util.zip.ZipFile.getEntry(Native Method)
at java.util.zip.ZipFile.getEntry(ZipFile.java:328)
- locked <0xa1b04418> (a java.util.jar.JarFile)
at java.util.jar.JarFile.getEntry(JarFile.java:253)
at java.util.jar.JarFile.getJarEntry(JarFile.java:236)
at 
org.apache.catalina.webresourc

Re: [OT] CVE-2019-0232 & CVE-2020-1938


All,

On 7/15/24 13:24, Jurevich, Aidan wrote:

Hi,
My organization has a few devices that have the file tomcat-juli-8.5.57.jar 
installed on them via the program Altair and are showing up as vulnerable to 
CVE-2019-0232 and CVE-2020-1938, which according to your documentation seems to 
be fixed for this version of the file. This seems to be an issue with Microsoft 
Defender being unable to read the version of the file. I was just making sure 
for our records that this issue has been solved as well as checking to see if 
you had any recommendations about how we can get this file to stop popping up 
as vulnerable.


Altair seems to have reproduced Tomcat's documentation with very little 
editing and absolutely no credit to the project on this page:

https://help.altair.com/2023/panopticon/realtimeinstall/onlinehelp/156_ConfiguringApacheTomcatLogs1.htm

:/

-chris

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

Re: CVE-2019-0232 & CVE-2020-1938


Aiden,

On 7/15/24 16:36, Christopher Schultz wrote:

Aiden,

On 7/15/24 13:24, Jurevich, Aidan wrote:

My organization has a few devices that have the file
tomcat-juli-8.5.57.jar installed on them via the program Altair and
are showing up as vulnerable to CVE-2019-0232 and CVE-2020-1938,
which according to your documentation seems to be fixed for this
version of the file.
If you are not enabling the CGI servlet (which is disabled by default), 
then you are not vulnerable to CVE-2019-0232.


If you are not using AJP to proxy traffic between a reverse proxy (e.g. 
IIS, Apache httpd, nginx, etc.) and Tomcat, then you are not vulnerable 
to CVE-2020-1938.


I'm interested to know why Altair is installing that specific version of 
that file into your environment, and, honestly, why ANY version of that 
file into your environment. If Tomcat is not being used, then 
tomcat-juli-x.y.z.jar should be completely useless. If Tomcat *is* being 
used, then /all of Tomcat should be upgraded/ beyond 8.5.57 as there are 
known published security vulnerabilities that have been fixed in later 
versions.


The JULI package seems to have been removed in Tomcat 8.5.4[1][2] and 
I'm curious as to why that file has that particular version number.



This seems to be an issue with Microsoft Defender being unable to
read the version of the file. I was just making sure for our records
that this issue has been solved as well as checking to see if you had
any recommendations about how we can get this file to stop popping up
as vulnerable.


Oh, to directly answer your question I would say:

1. Ask Altair what's up with that file

and

2. Ask Altair how to suppress the warning

Sorry, I know that's not what you wanted to hear. If you were running a 
stock Tomcat build, I'd say "just upgrade and you will be fine" but 
apparently you are running another vendor's product who may or may not 
be using Tomcat and "just upgrade" may not be something that is either 
possible or easy. If Altair directed you to us, you should go back to 
them and say "I pay *you* to support your own software, so support it" 
and hold them responsible for this kind of thing.


-chris

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

Re: CVE-2019-0232 & CVE-2020-1938


Aiden,

On 7/15/24 13:24, Jurevich, Aidan wrote:

My organization has a few devices that have the file
tomcat-juli-8.5.57.jar installed on them via the program Altair and
are showing up as vulnerable to CVE-2019-0232 and CVE-2020-1938,
which according to your documentation seems to be fixed for this
version of the file.
If you are not enabling the CGI servlet (which is disabled by default), 
then you are not vulnerable to CVE-2019-0232.


If you are not using AJP to proxy traffic between a reverse proxy (e.g. 
IIS, Apache httpd, nginx, etc.) and Tomcat, then you are not vulnerable 
to CVE-2020-1938.


I'm interested to know why Altair is installing that specific version of 
that file into your environment, and, honestly, why ANY version of that 
file into your environment. If Tomcat is not being used, then 
tomcat-juli-x.y.z.jar should be completely useless. If Tomcat *is* being 
used, then /all of Tomcat should be upgraded/ beyond 8.5.57 as there are 
known published security vulnerabilities that have been fixed in later 
versions.


The JULI package seems to have been removed in Tomcat 8.5.4[1][2] and 
I'm curious as to why that file has that particular version number.



This seems to be an issue with Microsoft Defender being unable to
read the version of the file. I was just making sure for our records
that this issue has been solved as well as checking to see if you had
any recommendations about how we can get this file to stop popping up
as vulnerable.
I would be curious to find out why this file is there *at all*. It seems 
to have no business being anywhere.


But if it really is some kind of misnamed Tomcat logging library from 
the distant past, it cannot make you vulnerable to either CVE referenced 
above.


Hope that helps,
-chris

[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=58588
[2] 
https://tomcat.apache.org/tomcat-8.5-doc/changelog.html#Tomcat_8.5.4_(markt)


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

Re: Reg: tomcat CPU spikes


Jalaj,

On 7/15/24 15:03, Jalaj Asher wrote:

Yeah I was wondering the same as this has been in place since a few
years now atleast 4 years since cachingAllowed had some changes in
tomcat 8 which was resulting in it caching all static content as well
as jsps and jars and our though process was if we have static content
being cached on the client end and jsps in the work folder each time
on access we don’t need the cache.

Does the cache actively hurt you?


Is there a way to cache just the jars and not every thing else in memory ?


I think the short answer is "no there is not a way to do this" but I may 
be wrong.


The long answer might be "maybe, but you will have to play games with 
 and  and maybe some other things to get it 
working.


I would save yourself some complexity and simply enable caching.

-chris


-Original Message-
From: Christopher Schultz 
Sent: Friday, July 12, 2024 4:02 PM
To: users@tomcat.apache.org
Subject: Re: Reg: tomcat CPU spikes

Attention! - This email has originated from an External Source outside of 
eClinicalWorks. Always use caution when opening attachments, clicking links, or 
when responding to this email. If you feel this is a phishing scam, please use 
the Phish Alert Report button in Outlook.


Jalaj,

On 7/12/24 10:19, Jalaj Asher wrote:

Thank you Chuck and John for the responses.

Just a few points from the things you highlighted and wanted me to
check 1. unpackwar is set to true. I checked and was informed that we need
that to be true for a specific war file.
2. cachingAllowed=false. We keep it as false across the board.


Well... that'll do it. In order to locate resources, Tomcat needs to sift 
through all of those JAR files every time. Scanning ZIP files is expensive.

You might want to reconsider this particular setting in your environment.


Also the reason I shared 2 different stacks is to highlight that the
problem does not occur post restart or with any specific part of the
application like the parser going in a loop but it kicks of at random
times impacting multiple tomcats. But all having the same stack
waiting on archiveresourceset and java.util.zip.

My only question would be "why is this only now coming to your attention? 
Things should have been behaving this way .. for a long time.


I am working on getting both types of stacks to share here as well.

Had a question we just have one war file if unpack war is triggered
why should it impact loading jars from the entire webapp lib ?


Because WEB-INF/lib is full of JAR files that need to be scanned every tie you 
try to load ... anything. Since you have disabled caching, it has to re-check 
every file for every resource-load request.

-chris


-Original Message-
From: Chuck Caldarale 
Sent: Wednesday, July 10, 2024 6:19 PM
To: Tomcat Users List 
Subject: Re: Reg: tomcat CPU spikes

Attention! - This email has originated from an External Source outside of 
eClinicalWorks. Always use caution when opening attachments, clicking links, or 
when responding to this email. If you feel this is a phishing scam, please use 
the Phish Alert Report button in Outlook.



On Jul 10, 2024, at 17:02, Jalaj Asher  
wrote:

Sharing another stack to see if this can give any more insights.this thread is 
the tomcat main thread was loading about 65MB of data.

"main" #1 prio=5 os_prio=0
java.lang.Thread.State: RUNNABLE
   at java.util.zip.ZipFile.getEntry(Native Method)
   at java.util.zip.ZipFile.getEntry(ZipFile.java:328)
   - locked <0xa1b04418> (a java.util.jar.JarFile)
   at java.util.jar.JarFile.getEntry(JarFile.java:253)
   at java.util.jar.JarFile.getJarEntry(JarFile.java:236)
   at 
org.apache.catalina.webresources.AbstractSingleArchiveResourceSet.getArchiveEntry(AbstractSingleArchiveResourceSet.java:97)
   at 
org.apache.catalina.webresources.AbstractArchiveResourceSet.getResource(AbstractArchiveResourceSet.java:249)
   at 
org.apache.catalina.webresources.StandardRoot.getResourceInternal(StandardRoot.java:272)
   at 
org.apache.catalina.webresources.StandardRoot.getResource(StandardRoot.java:213)
   at 
org.apache.catalina.webresources.StandardRoot.getClassLoaderResource(StandardRoot.java:220)
   at 
org.apache.catalina.loader.WebappClassLoaderBase.findClassInternal(WebappClassLoaderBase.java:2348)
   at 
org.apache.catalina.loader.WebappClassLoaderBase.findClass(WebappClassLoaderBase.java:875)
   at 
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1376)
   - locked <0xf24fc728> (a java.lang.Object)
   at 
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1220)
   at java.lang.Class.forName0(Native Method)
   at java.lang.

Re: Ubuntu Tomcat package maintenance

2024-07-12 Thread Christopher Schultz


Joel,

On 7/11/24 16:13, Joel Griffith wrote:

A year and a half ago I had to stop updating Tomcat because a Ubuntu
packaging bug force-changes file ownership of the Tomcat installation.  I'm
trying to get in touch with the package maintainers to have that fixed.

`apt-cache show tomcat` gives ubuntu-devel-disc...@lists.ubuntu.com as the
maintainers' mailing list.  I tried emailing it, but my posting was blocked
"pending moderator review" since I'm not a member of that list.  That was a
year and a half ago, and I've heard nothing.

I posted a bug under the Tomcat package on Ubuntu's Launchpad bug tracker,
but that has sat similarly ignored for the past year and a half.

Can anyone on this list help me get in touch with the Ubuntu package
maintainers for Tomcat?  Surely there's someone who can get me a degree or
two closer to them.


Do you know if the package you want is actually from Ubuntu or from 
upstream Debian?


-chris

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

Re: Reg: tomcat CPU spikes

2024-07-12 Thread Christopher Schultz


Jalaj,

On 7/12/24 10:19, Jalaj Asher wrote:

Thank you Chuck and John for the responses.

Just a few points from the things you highlighted and wanted me to check
1. unpackwar is set to true. I checked and was informed that we need
   that to be true for a specific war file.
2. cachingAllowed=false. We keep it as false across the board.


Well... that'll do it. In order to locate resources, Tomcat needs to 
sift through all of those JAR files every time. Scanning ZIP files is 
expensive.


You might want to reconsider this particular setting in your environment.


Also the reason I shared 2 different stacks is to highlight that the
problem does not occur post restart or with any specific part of the
application like the parser going in a loop but it kicks of at random
times impacting multiple tomcats. But all having the same stack
waiting on archiveresourceset and java.util.zip.
My only question would be "why is this only now coming to your 
attention? Things should have been behaving this way .. for a long time.



I am working on getting both types of stacks to share here as well.

Had a question we just have one war file if unpack war is triggered
why should it impact loading jars from the entire webapp lib ?


Because WEB-INF/lib is full of JAR files that need to be scanned every 
tie you try to load ... anything. Since you have disabled caching, it 
has to re-check every file for every resource-load request.


-chris


-Original Message-
From: Chuck Caldarale 
Sent: Wednesday, July 10, 2024 6:19 PM
To: Tomcat Users List 
Subject: Re: Reg: tomcat CPU spikes

Attention! - This email has originated from an External Source outside of 
eClinicalWorks. Always use caution when opening attachments, clicking links, or 
when responding to this email. If you feel this is a phishing scam, please use 
the Phish Alert Report button in Outlook.



On Jul 10, 2024, at 17:02, Jalaj Asher  
wrote:

Sharing another stack to see if this can give any more insights.this thread is 
the tomcat main thread was loading about 65MB of data.

"main" #1 prio=5 os_prio=0
   java.lang.Thread.State: RUNNABLE
  at java.util.zip.ZipFile.getEntry(Native Method)
  at java.util.zip.ZipFile.getEntry(ZipFile.java:328)
  - locked <0xa1b04418> (a java.util.jar.JarFile)
  at java.util.jar.JarFile.getEntry(JarFile.java:253)
  at java.util.jar.JarFile.getJarEntry(JarFile.java:236)
  at 
org.apache.catalina.webresources.AbstractSingleArchiveResourceSet.getArchiveEntry(AbstractSingleArchiveResourceSet.java:97)
  at 
org.apache.catalina.webresources.AbstractArchiveResourceSet.getResource(AbstractArchiveResourceSet.java:249)
  at 
org.apache.catalina.webresources.StandardRoot.getResourceInternal(StandardRoot.java:272)
  at 
org.apache.catalina.webresources.StandardRoot.getResource(StandardRoot.java:213)
  at 
org.apache.catalina.webresources.StandardRoot.getClassLoaderResource(StandardRoot.java:220)
  at 
org.apache.catalina.loader.WebappClassLoaderBase.findClassInternal(WebappClassLoaderBase.java:2348)
  at 
org.apache.catalina.loader.WebappClassLoaderBase.findClass(WebappClassLoaderBase.java:875)
  at 
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1376)
  - locked <0xf24fc728> (a java.lang.Object)
  at 
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1220)
  at java.lang.Class.forName0(Native Method)
  at java.lang.Class.forName(Class.java:348)
  at com.sun.beans.finder.ClassFinder.findClass(ClassFinder.java:67)
  at 
com.sun.beans.finder.ClassFinder.findClass(ClassFinder.java:110)
  at 
com.sun.beans.finder.InstanceFinder.instantiate(InstanceFinder.java:93)
  at 
com.sun.beans.finder.InstanceFinder.find(InstanceFinder.java:66)
  at 
java.beans.Introspector.findExplicitBeanInfo(Introspector.java:448)
  at java.beans.Introspector.(Introspector.java:398)
  at java.beans.Introspector.getBeanInfo(Introspector.java:173)
  at 
org.springframework.beans.CachedIntrospectionResults.getBeanInfo(CachedIntrospectionResults.java:255)



Is there some configuration setting in Spring that would disable caching? (I’m 
not really knowledgeable about Spring.)

There should be more in the stack trace that would show what’s triggering the 
getBeanInfo() calls. Tomcat won’t be doing the lookup unless something asks for 
it.

   - Chuck


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


CONFIDENTIALITY NOTICE TO RECIPIENT: This transmission contains confidential 
information belonging to the sender that is legally privileged and p

Re: Win10 installation progress

2024-07-09 Thread Christopher Schultz

und your project online including source. It's going to
take a bunch of work to get this going but it's not that bad. The major
effort will be that you can't use the "invoker servlet" anymore where
you make a call to "/foo.bar.Baz" and get your foo.bar.Baz servlet to be
called. You MUST explicitly-define each servlet and map them to URL
patterns these days.

If you know all the servlet names you know you need to make public, you
can just loop through them and do this:

foo.bar.Baz
foo.bar.Baz

// ... other definitions ...

Then:

foo.bar.Baz
/foo.bar.Baz

// ... other definitions ...

Put these into WEB-INF/web.xml with a proper XML envelope for web.xml.
For example:

http://xmlns.jcp.org/xml/ns/javaee";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd";
version="4.0">

(servlet stuff from above)

Note that I copied the header and footer of this XML document from
Tomcat's conf/web.xml file.

There are a whole lot of other recommendations I would have for your
application, but my guess is that you "just want to get it working"
before doing anything else.

-chris

dennis de
champeaux--
Home page: rs6.risingnet.net/~ddccMarketing site: www . OntoOO.comKindle
books: Side Effects: Impacts on the 21st
Century::https://www.amazon.com/-/es/Dennis-Champeaux-ebook/dp/B09MHJ5W48
Even if not
true::https://www.amazon.com/-/es/Dennis-Champeaux-ebook/dp/B09Y4WR9J7 9/11::
They had the Sun in their
Eyeshttps://www.amazon.com/11-They-had-their-Eyes-ebook/dp/B0CMQ2WSK9https://www.amazon.nl/dp/B0CMQ2WSK9

On Tuesday, May 21, 2024 at 08:38:02 AM PDT, Christopher Schultz
wrote:

Hello,

On 5/18/24 23:40, DdC wrote:

Gave up on installing 9.0.88. on Win10.

Why did you give up? ZIP installation is a single command (either via
CMD or UI shell). EXE installer is pretty straightforward, too. There's
also a third-party installer that has a few more features including the
ability to upgrade an existing installation. (I recommend against
upgrading an existing installation specifically, but that's not a
recommendation against that third-party installer.)

Do you mean you gave up trying to get your application running on it?

Succeeded with 10.1.23 andjdk-18.0.2.1.

Why Java 18? It's been EOL for years at this point. You should use Java
21 these days for anything new.

Did you know that Tomcat 10 is fundamentally different than previous
versions?

The lib directory has j2ee.jar, which I have used in earliertomcat versions.

What does j2ee.jar contain? That seems so unspecific as to be problematic.

Compilation of a system was OK apart from some warnings because Java
has changed since the code was written.

There is a web.xml file in WEB-INF.

Okay...

Invoking a servlet gives a 500 error with the ominous complaint:
class su.SUlogin cannot be cast to jakarta.servlet.Servlet
(su.SUlogin is in unnamed module of loader org.apache.catalina ...
) Looks like that my code is quite out of date.Any suggestion for a
fix?Going back to an earlier tomcat?

Did you read the migration guide for Tomcat 10.1?

I would highly recommend going back to 9.0 for the time being. If you
remove j2ee.jar, does your project compile? If not, what errors do you
get (missing classes, of course, but what major packages are missing)?

j2ee.jar sounds like an uber-jar with "everything we need in it" without
any specificity. You should replace that with modern, separate libraries
that support your application.

-chris

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

Re: Persistent Manager Implementation Question

2024-07-08 Thread Christopher Schultz

{
 return "Session ID: " + sessionId + ", Attribute not found";
 }
}

and also added a filter to validate to create it correctly

@Component
public class SessionValidationFilter extends OncePerRequestFilter {

 protected void doFilterInternal(HttpServletRequest request, 
HttpServletResponse response, FilterChain filterChain) throws ServletException, 
IOException {
 String requestURI = request.getRequestURI();

 // Exclude the create-session endpoint from filtering
 if (requestURI.equals("/demo/create")) {
 filterChain.doFilter(request, response);
 return;
 }

 HttpSession session = request.getSession(false); // Do not create 
session if it doesn't exist

 if (session != null && session.getId() != null) {
 // Session is valid, proceed with the request
 filterChain.doFilter(request, response);
 } else {
 // Session is invalid, return an error response
 response.sendError(HttpServletResponse.SC_UNAUTHORIZED, "Session 
expired or not authenticated");
 }
 }
}


El lun, 12 feb 2024 a las 9:18, Christopher Schultz (<
ch...@christopherschultz.net>) escribió:


Miguel,

On 2/8/24 15:49, Miguel Vidal wrote:

Im trying to configure correctly in 2 different applications :

Persistent

Manager Implementation using a mysqldb as a datasource.


Do you have both PersistentManager configurations pointing at the same
database and same set of tables? I think it will be rare to have session
id collisions, but configuring both applications to use the same storage
may cause very difficult to discover bugs under high usage.

It will also increase lock contention needlessly across the two
applications.

-chris


In one of them that is a legacy project i have some dependencies as


  org.springframework
  spring-core
  ${spring.framework.version}



  org.springframework
  spring-context
  ${spring.framework.version}


and it is already doing the registry of the sessions in my bd.
but in the other app im using a spring boot with the same configuration.
I'm not able to see any registration of the sessions in my db. After the
deploy of my app in a tomcat server and hit any resource example
/test/resource im able to see the response correctly but i just want to
know if this  Persistent Manager Implementation is only for legacy

apps? or

why is running in one and in the other is not.

this is my xml for both




  
  
  

  
timeBetweenEvictionRunsMillis="${jdbc.pool.timeBetweenEvictionRunsMillis}"



minEvictableIdleTimeMillis="${jdbc.pool.minEvictableIdleTimeMillis}"

  validationQuery="select 1"
  validationInterval="${jdbc.pool.validationInterval}"
  testOnBorrow="true"
  removeAbandoned="true"


removeAbandonedTimeout="${jdbc.pool.removeAbandonedTimeout}"

  logAbandoned="true"


jdbcInterceptors="org.apache.tomcat.jdbc.pool.interceptor.ResetAbandonedTimer"

  testWhileIdle="true"
  username="${jdbc.username}"
  password="${jdbc.password}"
  driverClassName="com.mysql.jdbc.Driver"


url="jdbc:mysql://${jdbc.host}:${jdbc.port}/tomcat?autoReconnect=true"/>



jdbcInterceptors="org.apache.tomcat.jdbc.pool.interceptor.ConnectionState;

  org.apache.tomcat.jdbc.pool.interceptor.StatementFinalizer;
  org.apache.tomcat.jdbc.pool.interceptor.ResetAbandonedTimer"

these 2  are the guides where i learn the mayority how to do it


https://svn.apache.org/repos/asf/tomcat/archive/tc4.1.x/trunk/container/catalina/docs/JDBCStore-howto.html



https://gerrytan.wordpress.com/2013/08/21/tomcat-7-jdbc-session-persistence/


im going to attach the code that im trying to know why is not working.



-
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: Inquiry about CVE-2024-5535 Vulnerability in Tomcat 10.1.20 Version

2024-07-08 Thread Christopher Schultz


Peyton,

On 7/7/24 23:50, Zhong, Peyton wrote:

Because OpenSSL is one of the most widely used open-source cryptographic 
libraries for implementing secure communications on the internet, it is 
essential for us to upgrade to secure versions to mitigate various threats, 
especially for software supply chain threats. To conduct risk assessments for 
each vulnerability to mitigate risks is the last resort, because it still 
remains residual risks from software supply chain perspective.

CVSS is used in security to provide a standardized method for assessing the 
severity of security vulnerabilities.

Although CVE-2024-5535 was rated as low in OpenSSL, it is rated as 9.1 
CRITICAL
 from Source: CISA-ADP. With that, we could not underestimate such issue. Hope you can understand 
my concerns.


Do you understand why it was rated LOW by OpenSSL and why it was rated 
CRITICAL by NVD?


Are you aware that CVE-2024-5535 does not affect tcnative? This is one 
of several reasons we did not race to issue an updated version of 
tcnative, etc.



In conclusion, we anticipate the upcoming release of Tomcat Native, which will 
incorporate the latest OpenSSL version and be included in the new Tomcat 
release. Thank you.


I look forward to your full participation in the voting process when 
tcnative.next is proposed for voting.


-chris


From: Mark Thomas 
Date: Sunday, 7 July 2024 at 2:05 AM
To: users@tomcat.apache.org 
Subject: Re: Inquiry about CVE-2024-5535 Vulnerability in Tomcat 10.1.20 Version
[You don't often get email from ma...@apache.org. Learn why this is important 
at https://aka.ms/LearnAboutSenderIdentification ]

On 06/07/2024 05:08, Zhong, Peyton wrote:

Dear Tomcat Community,

I am writing to inquire about the potential impact of the recently detected critical vulnerability: 
CVE-2024-5535>
 (9.1 CRITICAL / CVSS v3), in OpenSSL 3.0.13 on the Tomcat 10.1.20 version. According to Black Duck 
Binary Analysis (BDBA) scans, this vulnerability has been identified within the Tomcat 10.1.20 version. 
There are other detected vulnerabilities inside OpenSSL on Tomcat, such as CVE-2024-4603
The detected file is: apache-tomcat-10.1.20/bin/tcnative-2.dll

Given this disconcerting discovery, we are seeking clarification on how 
CVE-2024-5535 may affect the Tomcat 10.1.20 version. It is of utmost importance 
for us to understand the implications of this vulnerability and to identify any 
available mitigations or patches to address this issue.

Your prompt attention to this matter is highly valued, and we would be grateful 
for any assistance or guidance you can provide to help us navigate this 
potential security concern.

Thank you for your time and consideration.


Another illustration of why CVSS scores are a bad idea.

Did you read the description from the OpenSSL project for CVE-2024-5535?
Its severity is low, not critical. If you did read the descrition, did
you check the Tomcat Native source code to see if Tomcat uses the method
in question?

Same questions for CVE-2024-4603.

For CVE-2024-4603 did you read the description from the OpenSSL project?
Are you using an affected configuration? If yes, can you switch to one
that isn't affected?

You have access to all the information you need to be able to answer
your questions yourself. If it is important to you as you say it is then
why are you asking us to do the work for you rather than doing it yourself?

There are no plans at present for a new Tomcat Native release to pick up
an updated OpenSSL version for the Windows binaries. However, given that
some valid/likely configurations are affected, it is probable that there
will be a Tomcat Native release some time this month so it can be picked
up for the August Tomcat releases.

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: Inquiry about CVE-2024-5535 Vulnerability in Tomcat 10.1.20 Version

2024-07-06 Thread Christopher Schultz


Peyton,

On 7/6/24 00:08, Zhong, Peyton wrote:

I am writing to inquire about the potential impact of the recently detected critical 
vulnerability: CVE-2024-5535 
(9.1 CRITICAL / CVSS v3), in OpenSSL 3.0.13 on the Tomcat 10.1.20 version. According 
to Black Duck Binary Analysis (BDBA) scans, this vulnerability has been identified 
within the Tomcat 10.1.20 version. There are other detected vulnerabilities inside 
OpenSSL on Tomcat, such as CVE-2024-4603, CVE-2024-2511.

The detected file is: apache-tomcat-10.1.20/bin/tcnative-2.dll

Given this disconcerting discovery, we are seeking clarification on how 
CVE-2024-5535 may affect the Tomcat 10.1.20 version. It is of utmost importance 
for us to understand the implications of this vulnerability and to identify any 
available mitigations or patches to address this issue.

Your prompt attention to this matter is highly valued, and we would be grateful 
for any assistance or guidance you can provide to help us navigate this 
potential security concern.

Thank you for your time and consideration.


Official Tomcat distributions from ASF ship with a statically-linked 
OpenSSL DLL for Windows. Those DLLs come from the Tomcat-Native project. 
Each release of Tomcat Native includes the most-recent version of 
OpenSSL at the time of its release. Often, Tomcat Native releases are 
tied to important OpenSSL releases for this reason (convenience 
statically-linked binary for Windows).


You can upgrade (almost) any Tomcat installation with (almost) any newer 
version of Tomcat Native you wish. It would probably be better to simply 
upgrade Tomcat itself which will include the latest version of Tomcat 
Native at the time of release.


It seems there is a new OpenSSL release 3.0.14 while Tomcats and Tomcat 
Natives after ~Feb 2024 include OpenSSL 3.0.13.


If you are not using Windows, then you can safely remove this file. If 
you are not using TLS, you can most likely safely remove this file. If 
you are not using Tomcat Native, then you can safely remove 
tcnative-2.dll from your environment. If you are not sure if tcnative is 
being used in your environment, you should find someone who is sure.


-chris

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

Re: Tomcat silently shuts down after 10 minutes - SOLVED

2024-07-06 Thread Christopher Schultz


Bryan,

On 7/5/24 17:08, Bryan Buchanan wrote:

Thanks all for the replies.

Turns out I needed to execute my "C" program with a "nohup" i.e.

$ nohup /usr/local/bin/ManageTomcat START

Tomcat was only stopping after about 10 mins because that's when I logged out. 
Doh !

In the business app code I now execute the above and regular users can now 
start and stop Tomcat as needed. So far seems to be working out OK.


Flag I read the whole thread before replying.

This (nohup) is pretty standard for any service-type thing on UNIX-like 
systems.


-chris

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

Re: Errors after upgrading to Tomcat 9.0.90

2024-07-03 Thread Christopher Schultz


Francesco,

On 7/2/24 05:44, Francesco Chicchiriccò wrote:

On 2024/06/27 14:47:48 Christopher Schultz wrote:

Rainer,

On 6/21/24 07:55, Rainer Jung wrote:

Am 20.06.24 um 17:52 schrieb Christopher Schultz:

Francesco,

On 6/20/24 09:03, Francesco Chicchiriccò wrote:

On 2024/06/20 12:18:15 Konstantin Kolinko wrote:

чт, 20 июн. 2024 г. в 13:25, Francesco Chicchiriccò
:


Hi there,
at Syncope we usually use the latest Tomcat versions to run a large
chunk of our integration tests.

In our master branch we relay on Tomcat 10.1.x, and upgrading to
10.1.25 from 10.1.24 went smooth as usual.

In our 3_0_X branch we relay on Tomcat 9.0.x; with 9.0.89
everything goes as expected, but with 9.0.90 we are getting the
exception [1].

Any idea of what could be changed in 9.0.90 within this regard?
Thank you.

[1] https://gist.github.com/ilgrosso/be1fb1f2ea205eef60fb221973f87b34



The "java.lang.IllegalStateException: The request object has been
recycled and is no longer associated with this facade" message means
that a Request object has been (illegally) stored and is accessed
outside of its lifecycle - when the underlying structures and buffers
have already been recycled and may have been reused to process
subsequent requests.

Mark wrote:

You could try explicitly setting discardFacades to false.


In general, not recommended.
https://tomcat.apache.org/tomcat-9.0-doc/security-howto.html#Connectors

Calling getScheme() might be safe (as IIRC the info will come from a
connector configuration), but anything beyond that may lead to either
false results or to security issues. It would be better to identify
and fix the underlying cause.


Are you suggesting there is something to fix on Syncope's or CXF's
code? Or rather on Tomcat?


This is a protection that Tomcat is providing to the application.
There is no known bug in Tomcat's code.

It's not clear to me whether Syncope's or CXF's code is retaining such
a reference, but, given the stack trace I would suspect that
UserServiceImpl in Syncope's code is where you should start looking.


As I am writing above, we have no issues with Tomcat 9.0.89 nor with
Tomcat 10.1.25.


It looks like this change was made in 9.0.90 *only* and was not ported
to the other June releases. Honestly, this change should have been
made to all active branches... I'm not sure why Rémy only applied it
to 9.0.x.


The default value for discardFacades is already "true" in 10.1 and 11
and the old system property
org.apache.catalina.connector.RECYCLE_FACADES no longer exists for
these. So setting discardFacades to "true" in 9.0.x makes the default
behavior consistent.


+1 thanks for pointing this out. This commit was Rémy aligning 9.0.x
with the other active branches, not making it /out/ of alignment.


No idea, why the application now shows different behavior for 9.0.x
and 10.1.x.

Agreed. But wrapping in HttpServletRequestWrapper, using Async, and
performing what the OP described as "multiplex[ing] the incoming request
onto atomic requests, injected to CXF service processing" sounds like a
recipe for retaining references to these objects after they go out of scope.


Hi Chris,
the fix mentioned above was exactly addressed to copy (as opposite as 
reference) the needed values from the original request.
While coding the fix, however, I've discovered that the Syncope master branch 
(run on Tomcat 10.1) was already updated to work this way, while the 3_0_X 
branch (run on Tomcat 9) was simply not as fresh.

Everything is back working as expected, thanks for information.

Finally, about:


If your application is retaining a reference to an HttpServletRequest
after the request has been completed, then your application has a bug.
You can tell me it doesn't have a bug, but it does. If you want
information from that request, you should copy it out of the request.


I just wanted to reassure you that my intention was not to deny there was an issue, just 
to explain that probably it was not much about "security and/or privacy".


I disagree. If you retain references to those objects, it's entirely 
possible to return data in a response to the wrong user. Or get 
information from a request whose user has changed out from underneath you.


Any time user A and user B can see each other's data, that's a privacy 
and/or security issue in my book.


-chris

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

Re: Many CLOSE_WAIT connections causing the app not available

2024-07-03 Thread Christopher Schultz


Stephen,

On 6/29/24 07:57, Stephen Stevie wrote:

Tomcat not configured on default port


  


Which port is most often showing in the CLOSE_WAIT state?


[...] it was working fine until the start of this year. After that,
it was once a month and now every alternate day, we are seeing this.

Has the usage pattern of your application changed at all? More users, etc.?

-chris


On Thu, Jun 27, 2024 at 9:58 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Stephen,

On 6/26/24 01:18, Stephen Stevie wrote:

We are using Apache Tomcat 8.5.49 and sometimes in a day, we see the
application is going unresponsive though the service is up and running

and

giving 503 (service unavailable error). When netstat for the port is run,
we see many CLOSE_WAIT connections. Once we restart the service, the
application is coming back and sometimes this comes back on its own.

We have not made any changes to Tomcat in recent times and it was working
fine until the start of this year. After that, it was once a month and

now

every alternate day, we are seeing this. We're using 16GB RAM Web Server

(2

servers) and can see 1k-1.5k users connected to the application in a day.


Please post your  configuration, minus any secrets.

-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: Compatibility Check Tomcat 10.1.x with IBM MQ 9.3.0.20

2024-06-28 Thread Christopher Schultz


Mohit,

On 6/27/24 14:31, Chaudhary, Mohit wrote:

We have installed Tomcat 10.1.1 in RHEL 8 server so we needed to
check if tomcat 10.1.1 is compatible with IBM MQ 9.3.0.20.


Tomcat doesn't have any message-queue-related components out of the box, 
so I would say "maybe?"


Is Google Chrome or Arduino compatible with IBM MQ? The answer might be 
the same.


-chris

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

Re: Possible penetration attempt or DOS attack: any suggestions on what can be done?


James,

On 6/27/24 11:47, James H. H. Lampert wrote:

On 6/27/24 8:01 AM, Christopher Schultz wrote:

"100 404s in a minute per-IP"


Actually, what I was seeing, once the webapp developer pointed me in the 
right direction, was several dozen 404s per *second* from a single IP.


Not sure if Fail2ban would even work in this situation: like the 
overwhelming majority of the customer Tomcat installations we've done, 
this one is running on an IBM Midrange box (AS/400, iSeries, or whatever 
IBM is calling it this week). Which is probably how the huge amount of 
CPU usage was so easy to spot: WRKACTJOB is more user-friendly than any 
Linux-equivalent (or Mac-equivalent or WinDoze-equivalent) I've seen.


Yeah... some lazy Google searches for "fail2ban" along with various 
synonyms for os/as/400 and ibm midrange don't come up with much.


I might reach-out to your IBM contacts and/or OS/400 "community" to see 
if anyone has any suggestions.


In the meantime, use whatever tools are at your disposal to just bin 
every connection from that IP.


I found an article from 1998 on getting rhe OS/400 firewall up and 
running. Evidently, there is a web interface for configuration. Maybe it 
won't be a huge headache to simply firewall that IP out of your environment.


-chris

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

Re: Possible penetration attempt or DOS attack: any suggestions on what can be done?


James,

On 6/27/24 11:36, James H. H. Lampert wrote:

On 6/27/24 8:01 AM, Christopher Schultz wrote:


Why aren't you seeing the source-IP in your own logs?


Because our webapp developer hadn't thought to put them into the log 
messages we generate. He did, however, direct us to the 
localhost_access_log files (where I quite frankly hadn't thought to 
look). And they turned out to mostly be from an IP address that doesn't 
return anything in a reverse DNS lookup.


That's fine. IPs are IPs. Just bad the IP.

You can also perform IP reverse-lookup which is hit-or-miss. I did the 
same on an IP that was obviously scanning us last week in the way you 
described, and I got many results each claiming that the IP was (a) 
Russian (b) Ukrainian (c) Belgian (d) Polish and a bunch of other things 
as well. So obviously it's not foolproof. But sometimes it says 
"Sandusky, OH" and you say "oops that's our data center" and have to 
figure out what that means for you.


Don't ban your own data center, it probably won't go well for you. :)

The filenames in the requests seem to run in alphabetical order, and 
cover a gamut from nonsense combinations of random letters to clinical 
terms for sexual anatomy(!).


Yep, it's just a stupid scanner.

Anyone who was *really* trying to get it would be doing it much more 
covertly. fail2ban would be a fine solution in this case.


-chris

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

Re: Many CLOSE_WAIT connections causing the app not available


Stephen,

On 6/26/24 01:18, Stephen Stevie wrote:

We are using Apache Tomcat 8.5.49 and sometimes in a day, we see the
application is going unresponsive though the service is up and running and
giving 503 (service unavailable error). When netstat for the port is run,
we see many CLOSE_WAIT connections. Once we restart the service, the
application is coming back and sometimes this comes back on its own.

We have not made any changes to Tomcat in recent times and it was working
fine until the start of this year. After that, it was once a month and now
every alternate day, we are seeing this. We're using 16GB RAM Web Server (2
servers) and can see 1k-1.5k users connected to the application in a day.


Please post your  configuration, minus any secrets.

-chris

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

Re: Many CLOSE_WAIT connections causing the app not available


Stephen,

On 6/26/24 09:31, Chuck Caldarale wrote:



On Jun 26, 2024, at 00:18, Stephen Stevie
 wrote:

We are using Apache Tomcat 8.5.49



Stop right there. Tomcat 8.5.x reached end-of-life earlier this year
and is no longer supported. The particular version you’re running is
over 4.5 years old, and many, many security and correctness fixes
have been implemented since. You really need to upgrade to a
supported version ASAP.


+1

I would say using Tomcat 8.5.100 should be okay for "a little while" as 
long as you have a plan to upgrade to something past 8.5.


I haven't heard a single complaint from anyone who upgraded from 8.5 to 
9.0 unless they were doing something out of the ordinary.


But you should really have a plan in-place NOW for moving to a supported 
version of Tomcat.


And using 8.5.49 is a really *really* bad idea for exactly the reasons 
Chuck has described above.


-chris

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

Re: Isolating the Root Cause of "Connection Refused"


Eric,

On 6/26/24 01:43, Eric Robinson wrote:

What is impact on memory utilization if we increase the acceptCount
value? There are 100 tomcat instances on the server. And would
maxThreads have to be increased to accommodate the extra
connections?


After reading more, I guess that's a dumb question.


:)


I'm trying to prevent connections from being rejected. As I
understand it, when the server hits the maxThreads limit, then
additional connections queue up, until the acceptCount value is
finally reached, and then new connections are rejected.


This is correct according to all documentation. But. Java's 
documentation is clear that acceptCount/backlog is a "hint" to the OS 
about what that value can be. The OS is under no obligation to (a) set 
the accept-queue size to anything specific (such as your desired value), 
(b) keep the accept-queue size consistent. The documentation for 
listen(2) on my Debian Linux system suggests that the backlog is 
actually respected but silently capped to the OS's max count which is 
4096 is anything remotely recent.


My guess is that Java didn't want to over-promise with the acceptCount 
since it's supposed to be cross-platform. While Linux will generally 
respect the acceptCount, it CAN be capped silently. Other OSs may always 
give a process the same acceptCount or so something else somewhat 
unexpected.


Since you are using Linux, I think you can bet on acceptCount working 
mostly as you expect, with the caveat that it might be capped at an 
environment-specific value (which is likely changeable if necessary).



Since I am seeing connection refusals, then it is possible that the
acceptCount limit is being reached.

I would say "probable".


If so, then it seems there are two ways to address this. I can either
increase acceptCount, which gives the server more time to make
threads are available, or I can increase maxThreads, in which case
more requests can be handled concurrently and the acceptCount may not
be reached.

+1


Both of these settings improve performance, but in different ways.
I wouldn't say that raising acceptCount "improves performance" but maybe 
"improves experience". It may effectively /decrease/ performance because 
connections accepted (into the accept queue) but that have to wait a few 
seconds to be serviced may result in clients hanging up the phone before 
they are serviced. Depending upon the details of the situation, your 
server may serve a request from a client who has already given-up on the 
response... and even re-submitted the same request. So you get to do 
double the work in that situation.


Unfortunately, there is no "timeout" for the accept-queue. Once a 
connection has been accepted (bad verb, since accept(2) is the call that 
the application makes to accept the connection) into the 
accept-queue/backlog, it will remain there until the application calls 
accept(2) or terminates, even if the client disconnects or 15 minutes 
goes by. There is no way to say "put them in the queue but after 5 
seconds go ahead and refuse the connection". It's "connect or refuse" at 
that point.



maxThreads improves performance by allowing more requests to be
processed concurrently, while acceptCount improves performance by
preventing connections from being refused, which requires requests to
be reissued by the client, and that is an expensive process.
I would argue the opposite: clients receiving "connection refused" go 
away quickly and cheaply. It's the ones who wait in the accept queue who 
are "expensive".



Which of these approaches is correct? I tend to think increasing
maxThreads is better if the server has enough memory and CPU.
However, since the impact on memory and CPU depend on the
characteristics of the app, that's not a question you can be expected
to answer.


Again, it all depends upon your clients, usage patterns, and the "price" 
of a refused connection. If you have (human) clients who get VERY upset 
if their connections are refused than you may need to either change 
client expectations or change your service configuration with the 
understanding that "waiting in line is better than being turned away". 
Nobody can answer this question for you: you will need to decide for 
yourself which is better.


Hope that helps,
-chris

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

Re: Isolating the Root Cause of "Connection Refused"


Eric,

On 6/25/24 20:10, Eric Robinson wrote:


No - Tomcat passes the acceptCount value to the TCP/IP stack of the
OS as part of listener socket initialization.


I thought of that after I sent my previous message.


the OS won't log this, since it's considered to be an application
error.


Assuming the problem is the acceptCount value, then it's technically
the app's fault for improperly initializing the socket listener.
Nevertheless, it would make sense for the OS to log a neighborly
message (perhaps optionally) along the lines of, "I rejected a
connection attempt because of the acceptCount setting you told me to
use." It would sure help with troubleshooting. As you pointed out,
the app can't log errors it does not know about, so nothing is logged
anywhere.

What is impact on memory utilization if we increase the acceptCount
value? There are 100 tomcat instances on the server. And would
maxThreads have to be increased to accommodate the extra
connections?


I suspect that your problem lies in the neighborhood of the acceptCount
value, so I think this is worthwhile pursuing.

You said that your clients have very different usage patterns. Perhaps
you can identify those that get the biggest bursts of traffic and
reconfigure only those to have higher acceptCount values? There is no
particular reason that you have to raise them all to 5000 or whatever.

The memory impact is likely negligible, especially with that insane
amount of RAM. I'm no Linux kernel expert, but I think there are
essentially no limits (other than physical RAM and avoiding swapping) on
the amount of memory that the kernel can use for this kind of thing. A
TCP backlog entry can't be THAT big. A few dozens of bytes or maybe even
a whole kilobyte and you have scads of RAM to spare.

maxThreads does not need to be increased. Think of acceptCount and 
maxThreads as sympathetic settings. If you never want any client to be 
turned-away, then set acceptCount/backlog to something "high". If you 
never want any client to wait a long time, set maxThreads to something 
"high". But of course your CPU(s) can only do so much work at once, so 
at some point setting maxThreads too high will just make things worse.


Do you have any reverse-proxy or similar out in front of any/all of 
these services? If so, you could turn "connection refused" into a HTTP 
503 response to clients. Of course, then you have the problem of tuning 
the reverse-proxy so that it doesn't turn anyone away...


"Connection refused" is one of TCP's ways of telling a client that the 
service isn't available. That can be because it's down completely or 
because it's being heavily-used. IMHO, "under heavy use" is an 
acceptable reason to return "connection refused" but your (paying) 
clients may disagree. How often are you getting reports of "connection 
refusals"? You should be able to monitor your processes to see the 
number of concurrent connections being processed, and see if they are 
reaching the various limits you have.


Any time your server's concurrent-request-count and max-thread-count are 
the same, it means your acceptCount/backlog is being used. Look for 
instances of those situations and re-tune those services to have a 
higher thread count.


Can you post an example  configuration? Are most of your 
servers configured with similar  configurations?


There are a lot of variables that go into these calculations, including 
connector type (BIO, NIO/2, APR, etc.), usage pattern (short requests 
versus long-running ones), use of async/websocket, etc. So more 
information would certainly help us help you.


-chris

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

Re: Isolating the Root Cause of "Connection Refused"


Eric,

On 6/25/24 14:22, Chuck Caldarale wrote:



On Jun 25, 2024, at 13:12, Eric Robinson  wrote:

I'm obviously not getting something. If I understand correctly, the purpose of 
the acceptCount param is to allow tomcat to reject connections even after the 
TCP stack has passed them to the java process. At that point, the request has 
made it through the OS all the way to tomcat, so if tomcat rejects it, then it 
should log a message... no?



No - Tomcat passes the acceptCount value to the TCP/IP stack of the OS as part of 
listener socket initialization. The accept queue is maintained entirely by the OS; 
Tomcat is not involved in the management thereof, other than taking requests off the 
accept queue with the listener thread for the . If connection 
requests arrive at the NIC fast enough to fill up the accept queue, excess ones are 
simply rejected by the OS.


+1

If the OS's TCP stack rejects a request because the backlog queue is 
full, the application is never notified. I've never even tried to see if 
this situation results in a syslog message or similar. You'd have to do 
some Linux kernel research and/or Rocky config research to see if you 
can coax that information out of the kernel. It would be one more attack 
vector: jut slam a server with connections and fill the disk with logs.


-chris

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

Re: How to configure Tomcat with a Managed Service Account when using LocalMachine certificates for TLS


Gavioto,

On 6/25/24 13:51, Gavioto 🕵 wrote:
Finally, I got a configuration that works with Certificate Storage. It 
is very specific, and I couldn't find any other until date.
It works, but in our environment there is a required manual step yet. I 
think it should be configured in Windows and is common for all programs 
requesting private key not special for Tomcat.
A dialog of Windows Security is shown asking to allow access, similar to 
UAC but for certificates.


Your image was stripped from your mailing-list post. Can you please 
*describe* this manual-step? Without the image, I fear your post has no 
usable content.



The server.xml configuration used is

|SSLEnabled="true">              certificateKeystoreType="Windows-MY-LOCALMACHINE" 
certificateKeystoreFile=""             certificateKeyAlias="tomcat"/>   
    |


This is the same as before, yes?

I continue my research trying to use different ciphers and properties, 
because I won't be able to use the standard without the . It is clear 
for me, that different internals libraries are used in Tomcat, so when I 
use the only the it doesn't work and it won't find the key in the storage.


Do you need to specify the Provider to use? Your sample code was 
manually-loading a specific JSSE Provider.


*For the purpose of the initial question, I consider this solutions as 
valid, as Tomcat is able to work with the Windows Local Machine 
Certificate Storage.*

Solution versions:

  * JDK 11.0.20+ or JDK version with fixed bug
_https://bugs.openjdk.org/browse/JDK-8286790
_
  * Tested with Tomcat 9.0.63
  * Tested in Windows 2019


*Thank you for your support. Hope this information is useful to crate a 
Use Case in the wiki.*


Some doubts are in the air yet, but it is essentially possible for 
Tomcat to work with this.


Two questions thats remaining for the future:

  *
How to disable or bypass the Windows Security dialog? Is it possible
to disable for specific Users/Services?


Does it show every time, or only once and after that it works without a 
dialog?



  *
Why if I use keyStoreType="windows-my-localmachine" directly in
 it doesn't find the certificate?


Do you mean certificateKeystoreType? Speling matters.

https://tomcat.apache.org/tomcat-9.0-doc/config/http.html#Special%20Features_SSL%20Support%20-%20Certificate_certificateKeystoreType

There is a note about key store types:

"
Key store types

In addition to the standard key store types (JKS and PKCS12), most Java 
runtimes support additional key store types such as Windows-ROOT, 
Windows-My, DKS as well as hardware security modules. Generally, to use 
these additional keystore types with a TLS Connector in Tomcat:


*Set the certificateKeystoreType and/or truststoreType Connector 
attribute (as appropriate) to the necessary type


*If a configuration file is required, set the 
certificateKeystoreFile and/or truststoreFile Connector attribute (as 
appropriate) to point to the file


*If no configuration file is required then you will almost certainly 
need to explicitly set the certificateKeystoreFile and/or truststoreFile 
Connector attribute (as appropriate) to the empty string ("")


*If a password is required, set the certificateKeystorePassword 
and/or truststorePassword Connector attribute (as appropriate) to the 
required password


*If no password is required then you will almost certainly need to 
explicitly set the certificateKeystorePassword and/or truststorePassword 
Connector attribute (as appropriate) to the empty string ("")

"

Note this last item. I'm not sure if it is required in your particular case.

-chris



*De:* Gavioto 🕵 
*Enviado:* martes, 25 de junio de 2024 15:27
*Para:* users@tomcat.apache.org 
*Asunto:* RE: How to configure Tomcat with a Managed Service Account 
when using LocalMachine certificates for TLS

- how are are starting Tomcat?
  Tomcat is starting as a service with "Domain\account1$" (Managed 
Service Account)


- is Tomcat installed as a Windows service?
  Yes

- which account is Tomcat running under?
  "Domain\account1$" (Managed Service Account) It is not a normal 
domain account used for the service.  Secure group managed service 
accounts - Microsoft Entra | Microsoft 
Learn>


Regarding the mean of "user" I'm referring to the user who is running 
the Tomcat Service. In this case, the Managed Service Account.



De: Mark Thomas 
Enviado: martes, 25 de junio de 2024 12:51
Para: users@tomcat.apache.org 
Asunto: Re: How to configure Tomcat with a Managed Service Account when 
using LocalMachine certificates for T

Re: PKCS#8 encryption algorithm unrecognized


Timothy,

On 6/25/24 10:39, Timothy Resh wrote:

In the
  SSLPassword="${KSENC(6qkaMErQ==; C:\Certificate\Keystore\Vessel.p12)}"

we defined a Class to convert the Encrypted password  and set the following
properties:
public class MyPropertySource implements
org.apache.tomcat.util.IntrospectionUtils.PropertySource
...
  public String getProperty(String arg0) {
 if (arg0.contains("KSENC(")) {

 System.setProperty("javax.net.ssl.keyStore",
keyStorePath);
 System.setProperty("javax.net.ssl.keyStorePassword",
clearText);
 System.setProperty("javax.net.ssl.trustStore",
trustStorePath);
 System.setProperty("javax.net.ssl.trustStorePassword",
clearText);
  }
...
}
This class will set the following properties at the beginning of Tomcat init

In my debugging I found that it could not determine the store properly.
So, I tried putting in the keystoreType="PKCS12 and now it works.

I hope this helps.  I'm still set up for debugging if you need something
looked at.


FYI I /think/ that all the javax.net.ssl.* properties are read only once 
during JSSE initialization. It's entirely possible that JSSE is 
configured *before* this code runs and it doesn't have any effect. For 
JVM-wide properties like these, it's best to set those system properties 
on the command-line instead of waiting for Java code to set them.


-chris

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

Re: [OT] ldap administration tool and error LDAP: error code 49 - Invalid Credentials


Shekhar,

On 6/25/24 01:40, Shekhar Dhotre wrote:

Is there any DLap admin tool available ? I want to manage IBM and openldap with 
it . trying to reset users password in IBM ldap but it fails with


"[root@camttvpws002 app]# ldapsearch -x -h //102.85.9.23 -D 
"ldap@seth.local" -b "dc=seth,dc=local" -w * 
"sAMAcountName=shekhdho"

ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)


My ldapsearch command does not take a -h argument for "host". It uses -H 
(capitalized), and it takes a proper URI like ldap://102.85.9.23 or 
ldaps://102.85.9.23


You should check the protocol (ldap or ldaps) and use the right one. 
Then check to see if your server can contact the LDAP server on that 
port (389 for ldap, 636 for ldaps). You can use telnet, nc, etc. to test 
connectivity.



[root@camttvpws002 ~]# tail -f /app/web/logs/RMA/RMA.log

2024-06-22 06:34:31,696{ INFO [http-bio-8443-exec-3] (RMAdao.java:5047) - after 
preparing the statement

2024-06-22 06:34:31,697{ INFO [http-bio-8443-exec-3] (RMAdao.java:5050) - 
application name is:RMA

2024-06-22 06:34:31,737{ERROR [http-bio-8443-exec-3] (RMAdao.java:5116) - The 
exception occurred is:ORA-00942: table or view does not exist


This looks like JDBC stuff, not LDAP.


2024-06-22 06:34:31,738{ERROR [http-bio-8443-exec-3] (CheckDownTime.java:60) - 
Exception Occurred : java.lang.NullPointerException

2024-06-22 06:34:31,739{ INFO [http-bio-8443-exec-3] (LoginAction.java:64) - 
Inside Action:- Method:fetchUserInfo

2024-06-22 06:34:31,739{ INFO [http-bio-8443-exec-3] (LoginAction.java:67) - 
The username is : shekhdho

2024-06-22 06:34:31,777{ERROR [http-bio-8443-exec-3] (Ldap.java:85) - Exception 
occurred :javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid 
Credentials]


That's pretty readable, but the cause could be one of several things.

Can you post your  configuration, minus any secrets?

-chris

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

Re: Possible penetration attempt or DOS attack: any suggestions on what can be done?


James,

On 6/24/24 17:57, James H. H. Lampert wrote:

On 6/24/24 12:03 PM, Tim Funk wrote:

Conversely, this is a good time for the developers to review
their server logging and tune it to be less verbose for these
normal exceptions. As well as implementing logging frameworks
and logging at the appropriate level (fatal through debug)


Thanks for your thoughts on the subject.

The primary problem isn't that the catalina.out file is enormous, nor 
that the log messages are too verbose (if anything, they're not verbose 
enough: a timestamp would help) ; it's that while the random filenames 
were being tried, in quick succession, the CPU usage of the JVM job 
skyrocketed, and legitimate traffic was probably having trouble getting in.


Hmm. Are you getting requests for the same (missing) resource over and 
over again, or many different ones? I suspect different, since attackers 
have a huge dictionary of "telltale resources" to identify a service as 
running one of many known-vulnerable services (e.g. Wordpress, JIRA, etc.).


Why aren't you seeing the source-IP in your own logs? If you are using a 
reverse-proxy and always getting the IP of the proxy, you should be able 
to (a) configure the reverse-proxy to provide its own IP to you and 
configure Tomcat to use that for logging and/or (b) look-up the same 
request in the proxy logs. Once you have that, you can ban.


Banning can be done in many ways.

One way would be just by-hand. If you see a huge number of requests from 
one IP, just ban it. If it's more than one IP, then you get to play 
whack-a-mole and automated solutions would be better.


Be careful with fail2ban (which I like a lot, but I've never used it 
with HTTP logs): you can easily ban people quickly who aren't actually 
attacking you. If you use fail2ban (or similar), I would be very 
conservative about its configuration. Basically, you choose the number 
of flags that have to be thrown per-IP per-time-interval. So something 
like "100 404s in a minute per-IP" would be conservative.


fail2ban is definitely available on Linux and probably also BSD. I think 
you are on AS/400 or something like that, right? And of course you'd 
want to ban as far up the chain as possible, at the reverse-proxy, TLS 
terminator, or load-balancer. I'm not sure exactly what options you have 
in that environment. fail2ban works directly with the OS's firewall, so 
on Linux that's iptables and on BSD that's generally ipfilter. If AS/400 
has a built-in firewall then it's possible fail2ban has a build for it.


Tim's suggestion of a WAF is a good one. I've tried to configure 
mod_security for Apache httpd and it's got like 100M rules and it 
immediately banned every one of our developers when we used it 
out-of-the-box. It is SUPER PARANOID about everything. If you are 
considering using mod_security, I would (a) run it only in a development 
/ testing environment and (b) run it in "audit mode" for a week or so 
and look at all the complaints it makes. I have had to specifically 
disable a LARGE number of checks to make it even partially usable.


-chris

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

Re: Errors after upgrading to Tomcat 9.0.90


Rainer,

On 6/21/24 07:55, Rainer Jung wrote:

Am 20.06.24 um 17:52 schrieb Christopher Schultz:

Francesco,

On 6/20/24 09:03, Francesco Chicchiriccò wrote:

On 2024/06/20 12:18:15 Konstantin Kolinko wrote:
чт, 20 июн. 2024 г. в 13:25, Francesco Chicchiriccò 
:


Hi there,
at Syncope we usually use the latest Tomcat versions to run a large 
chunk of our integration tests.


In our master branch we relay on Tomcat 10.1.x, and upgrading to 
10.1.25 from 10.1.24 went smooth as usual.


In our 3_0_X branch we relay on Tomcat 9.0.x; with 9.0.89 
everything goes as expected, but with 9.0.90 we are getting the 
exception [1].


Any idea of what could be changed in 9.0.90 within this regard? 
Thank you.


[1] https://gist.github.com/ilgrosso/be1fb1f2ea205eef60fb221973f87b34



The "java.lang.IllegalStateException: The request object has been
recycled and is no longer associated with this facade" message means
that a Request object has been (illegally) stored and is accessed
outside of its lifecycle - when the underlying structures and buffers
have already been recycled and may have been reused to process
subsequent requests.

Mark wrote:

You could try explicitly setting discardFacades to false.


In general, not recommended.
https://tomcat.apache.org/tomcat-9.0-doc/security-howto.html#Connectors

Calling getScheme() might be safe (as IIRC the info will come from a
connector configuration), but anything beyond that may lead to either
false results or to security issues. It would be better to identify
and fix the underlying cause.


Are you suggesting there is something to fix on Syncope's or CXF's 
code? Or rather on Tomcat?


This is a protection that Tomcat is providing to the application. 
There is no known bug in Tomcat's code.


It's not clear to me whether Syncope's or CXF's code is retaining such 
a reference, but, given the stack trace I would suspect that 
UserServiceImpl in Syncope's code is where you should start looking.


As I am writing above, we have no issues with Tomcat 9.0.89 nor with 
Tomcat 10.1.25.


It looks like this change was made in 9.0.90 *only* and was not ported 
to the other June releases. Honestly, this change should have been 
made to all active branches... I'm not sure why Rémy only applied it 
to 9.0.x.


The default value for discardFacades is already "true" in 10.1 and 11 
and the old system property 
org.apache.catalina.connector.RECYCLE_FACADES no longer exists for 
these. So setting discardFacades to "true" in 9.0.x makes the default 
behavior consistent.


+1 thanks for pointing this out. This commit was Rémy aligning 9.0.x 
with the other active branches, not making it /out/ of alignment.



No idea, why the application now shows different behavior for 9.0.x
and 10.1.x.
Agreed. But wrapping in HttpServletRequestWrapper, using Async, and 
performing what the OP described as "multiplex[ing] the incoming request 
onto atomic requests, injected to CXF service processing" sounds like a 
recipe for retaining references to these objects after they go out of scope.


-chris

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

Re: Errors after upgrading to Tomcat 9.0.90

2024-06-26 Thread Christopher Schultz


Francesco,

On 6/21/24 06:02, Francesco Chicchiriccò wrote:

On 2024/06/20 15:52:16 Christopher Schultz wrote:

Francesco,

On 6/20/24 09:03, Francesco Chicchiriccò wrote:

On 2024/06/20 12:18:15 Konstantin Kolinko wrote:

чт, 20 июн. 2024 г. в 13:25, Francesco Chicchiriccò :


Hi there,
at Syncope we usually use the latest Tomcat versions to run a large chunk of 
our integration tests.

In our master branch we relay on Tomcat 10.1.x, and upgrading to 10.1.25 from 
10.1.24 went smooth as usual.

In our 3_0_X branch we relay on Tomcat 9.0.x; with 9.0.89 everything goes as 
expected, but with 9.0.90 we are getting the exception [1].

Any idea of what could be changed in 9.0.90 within this regard? Thank you.

[1] https://gist.github.com/ilgrosso/be1fb1f2ea205eef60fb221973f87b34



The "java.lang.IllegalStateException: The request object has been
recycled and is no longer associated with this facade" message means
that a Request object has been (illegally) stored and is accessed
outside of its lifecycle - when the underlying structures and buffers
have already been recycled and may have been reused to process
subsequent requests.

Mark wrote:

You could try explicitly setting discardFacades to false.


In general, not recommended.
https://tomcat.apache.org/tomcat-9.0-doc/security-howto.html#Connectors

Calling getScheme() might be safe (as IIRC the info will come from a
connector configuration), but anything beyond that may lead to either
false results or to security issues. It would be better to identify
and fix the underlying cause.


Are you suggesting there is something to fix on Syncope's or CXF's code? Or 
rather on Tomcat?


This is a protection that Tomcat is providing to the application. There
is no known bug in Tomcat's code.

It's not clear to me whether Syncope's or CXF's code is retaining such a
reference, but, given the stack trace I would suspect that
UserServiceImpl in Syncope's code is where you should start looking.


As I am writing above, we have no issues with Tomcat 9.0.89 nor with Tomcat 
10.1.25.


It looks like this change was made in 9.0.90 *only* and was not ported
to the other June releases. Honestly, this change should have been made
to all active branches... I'm not sure why Rémy only applied it to 9.0.x.


I'd tend to think that such change should be applied to all active branches, 
for consistency.

Is there any issue referencing this change?
  

This is likely a long-standing bug in your application and it really
should be fixed. There is likely a security and/or privacy issue in the
application which this error is pointing-out to you.


Nope, nothing of that kind.


?


Syncope offers an OData-lilke batch feature [1] which implies, in
case of asynchronous processing request, to multiplex the incoming
request onto atomic requests, injected to CXF service processing.
If your application is retaining a reference to an HttpServletRequest 
after the request has been completed, then your application has a bug. 
You can tell me it doesn't have a bug, but it does. If you want 
information from that request, you should copy it out of the request.


If you are using an asynchronous request, then you also need to take 
care to only use that async request in the way it was intended to be 
used. Object lifetimes still apply.



The current error derives from the atomic requests being constructed
as HttpServletRequestWrapper subclasses from the original request: it
seems that, after the change in Tomcat 9.0.90, this has become
problematic - while it is still not for Tomcat 10.1.25, Wildfly,
Undertow and Payara, against which Syncope integration tests are also
run.
Wrapping a request in an HttpServletRequestWrapper does not count as 
copying it or the data it contains. That's wrapping it, and you still 
have a reference to the original request... through the wrapper.



We should have a fix ready, going to push it soon.


A fix is good, even if you weren't willing to admit there was a problem 
in the first place.


I wonder what the "fix" looks like for a non-bug in this context. I hope 
you haven't just made the problem worse.


-chris

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

Re: Errors after upgrading to Tomcat 9.0.90

2024-06-20 Thread Christopher Schultz


Francesco,

On 6/20/24 09:03, Francesco Chicchiriccò wrote:

On 2024/06/20 12:18:15 Konstantin Kolinko wrote:

чт, 20 июн. 2024 г. в 13:25, Francesco Chicchiriccò :


Hi there,
at Syncope we usually use the latest Tomcat versions to run a large chunk of 
our integration tests.

In our master branch we relay on Tomcat 10.1.x, and upgrading to 10.1.25 from 
10.1.24 went smooth as usual.

In our 3_0_X branch we relay on Tomcat 9.0.x; with 9.0.89 everything goes as 
expected, but with 9.0.90 we are getting the exception [1].

Any idea of what could be changed in 9.0.90 within this regard? Thank you.

[1] https://gist.github.com/ilgrosso/be1fb1f2ea205eef60fb221973f87b34



The "java.lang.IllegalStateException: The request object has been
recycled and is no longer associated with this facade" message means
that a Request object has been (illegally) stored and is accessed
outside of its lifecycle - when the underlying structures and buffers
have already been recycled and may have been reused to process
subsequent requests.

Mark wrote:

You could try explicitly setting discardFacades to false.


In general, not recommended.
https://tomcat.apache.org/tomcat-9.0-doc/security-howto.html#Connectors

Calling getScheme() might be safe (as IIRC the info will come from a
connector configuration), but anything beyond that may lead to either
false results or to security issues. It would be better to identify
and fix the underlying cause.


Are you suggesting there is something to fix on Syncope's or CXF's code? Or 
rather on Tomcat?


This is a protection that Tomcat is providing to the application. There 
is no known bug in Tomcat's code.


It's not clear to me whether Syncope's or CXF's code is retaining such a 
reference, but, given the stack trace I would suspect that 
UserServiceImpl in Syncope's code is where you should start looking.



As I am writing above, we have no issues with Tomcat 9.0.89 nor with Tomcat 
10.1.25.


It looks like this change was made in 9.0.90 *only* and was not ported 
to the other June releases. Honestly, this change should have been made 
to all active branches... I'm not sure why Rémy only applied it to 9.0.x.


This is likely a long-standing bug in your application and it really 
should be fixed. There is likely a security and/or privacy issue in the 
application which this error is pointing-out to you.


-chris

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

Re: Tomcat MySQL Connection Pooling JNDI lookup


Daniel,

On 6/19/24 16:37, Daniel Schwartz wrote:

I followed you instruction to move the context.xml file into the application 
WEB-INF directory and restored the original context.xml file in the tomcat conf 
directory, but the problem persists.  Very puzzling.


To be clear, I was recommending putting context.xml into META-INF and 
not WEB-INF.



Your remark regarding the MySQL login ID and password is well-taken, and I will 
change this when/if the system goes into production.

In the meantime, however, I have explored the current version of Glassfish.  I 
had been using Glassfish 4.1 years ago, and it had a nice interface for setting 
up database connection pooling.  You just had to input some parameters and it 
automatically generated all the necessary files in the appropriate directories. 
 That system would not work with any version of Java later than 1.8.

Then they upgrader to Glassfish 5.0, which would work with later versions of 
Java.  Unfortunately, when the upgraded version introduced a big that made the 
connection pooling module unusable.

Then I put that project on hold for a few years, and have now come back to it.

This is why I recently decided to explore Tomcat, as an alternative to 
Glassfish, since it wasn't working when I last left it.  Yesterday, however, I 
decided to look at the current version of Glassfish, and discovered that that 
old bug has now been fixed, and the connection pooling module once again works 
exactly as it did in version 4.1.  And the new version will work with Java 21.

So I do have something working now, and actually don't need Tomcat.  However, 
it does still bother me that I have been unable to get Tomcat to work.  The 
Tomcat people should consider developing a module like the one they have in 
Glassfish.


Web-based configuration tools are somewhat dangerous in our opinion. 
Yes, we have some (e.g. manager and host-manager) but they don't 
generally mess with configuration files.


JNDI connection pooling requires both the container and the application 
to be configured properly, and applications can be configured in myriad 
ways, so a tool to configure the pooling for your application would only 
go so far.


Patches are always welcome.

I'm still interested in why this isn't working. I've never seen a 
situation where JNDI wasn't working and Tomcat generated ZERO error 
messages. Is it possible that the files you are editing aren't the ones 
being deployed into the container? Are you using anything that might 
take control of any JNDI namespaces in the JVM? For me, this always 
"just works" and so no configurator-style tool is necessary :/


-chris


-Original Message-
From: Christopher Schultz 
Sent: Wednesday, June 19, 2024 12:34 PM
To: users@tomcat.apache.org
Subject: Re: Tomcat MySQL Connection Pooling JNDI lookup

Daniel,

On 6/19/24 11:40, Daniel Schwartz wrote:

Dear Felix,

Thank you for your reply.  The connector jar file is at

 C:\Program
Files\apache-tomcat-10.1.24\lib\mysql-connector-j-8.4.0.jar

The latest entry in catalina.2024-06-17.log is copied below.  The latest entry 
in localhost.2024-06-17.log is copied after that.  The two entries are 
essentially identical.

The cause of the failure is reported as

 Caused by: java.lang.NullPointerException: Cannot invoke 
"javax.sql.DataSource.getConnection()" because "this.dataSource" is null
at
com.worldholidaysandevents.restjsonwebservice.HolidaysRestJsonWebServi
ceResource.getJsonCountries(HolidaysRestJsonWebServiceResource.java:56
)

However, this is turn is caused by the failure reported in my previous
email on the line

 dataSource = (DataSource) ctx.lookup("jdbc/holidays");

in a file called DataSourceSingleton.java, which is invoked by the 
getJsonCountries method.  The method is supposed to extract a list of countries 
from the database, but the list is returned as null since the JNDI lookup 
fails.  I identified this failure by putting print statements immediately 
before and after this line.  The statement before the line outputs its message, 
and the one after this line does not.   You can see this in the Command Prompt 
where Tomcat is running.  I copied this error message in my previous email.



Your code looks fine. Fully-specifying the JNDI URL is basically optional, but 
it wouldn't hurt.

I would move that context.xml file into your application under 
META-INF/context.xml and restore the original conf/context.xml because you do 
not need that JNDI resource to be made available to every application on your 
server (right?).

I would also recommend NOT using the "root" user for your database connection. I realize 
that you are probably "just getting started" but it would be best to use an 
application-specific user for your database, and to get into that habit as soon as possible.

--

Re: Tomcat 9 symlinks ?


Chuck,

On 6/19/24 15:49, Chuck Caldarale wrote:



On Jun 19, 2024, at 14:42, Stephen Tenberg  wrote:

You asked why  path="" instead of path="foo" in context at server.xml?

That was our attempt to mount this application at "/" instead of at "/foo"
which is a requirement here.



Just deploy the application as ROOT (case matters) rather than foo.


+1

And this is trivial when the application is self-contained with a 
META-INF/context.xml which *should not specify the path* because all you 
have to do is re-name the directory or WAR file and you are done.


-chris

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

Re: Not able to start WebApp on JDK 11


Shivaanand,

On 6/18/24 13:29, Shivaanand Verma wrote:

We are having a Jersey Servlet application running on the 9.0.80 version of
Apache Tomcat. Recently we've been trying to migrate our application from
JDK 8 to JDK 11.

The application used to run smoothly on JDK 8, but when compiled against
JDK 11, it does not start up. The tomcat webapps directory expands the
application.war file into its directory but the control never reaches
initialising classes. We are not able to understand what is blocking the
application from running since catalina.out and juli.log are not showing
any exceptions or error traces.

We've enabled debug logging using the logging.properties file too, but
still we don't see any logs in catalina.out. Is there a way to determine
why is tomcat not able to start the application or what classes it is
trying to load and is failing to do so?


Try running the application from the console like this:

$ cd $CATALINA_BASE
$ $CATALINA_HOME/bin/catalina.sh run
[console output goes here]

This should emit all error messages.

Have you tried building with Java 8 and running Tomcat on Java 11 with 
no other changes? There is no particular reason to re-build with Java 11 
if you don't want to.


-chris

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

Re: Tomcat 9 symlinks ?


Stephen,

On 6/19/24 13:55, Stephen Tenberg wrote:

Hello I have scoured the web trying to get symlinks working for jsp pages
or folders in Tomcat 9 using Ubuntu 20.04. Here is how to repeat the issue,
and what I have tried.

1. Create a new folder in webapps, say "foo"

2. Put HelloWorld.jsp there

3. (I restarted Tomcat just in case) Verify it works at
localhost:8080/foo/HelloWorld.jsp

4. Put a soft symlink there: ln -s /opt/tomcat/webapps/foo/HelloWorld.jsp
/opt/tomcat/webapps/foo/Link.jsp

5. (restart) Verify that localhost:8080/foo/Link.jsp soft fails with
nothing in the log as if it does not exist.

WHAT I TRIED:

First I put this in the default host "localhost" in server.xml:

  
   




Why path="" instead of path="foo"?

In fact... why bother with a  element at all? The presence of 
the "foo" directory will automatically deploy an application on /foo. 
Yes, in order to "allow linking" you will need a  to set it on, 
but that should be under webapps/foo/META-INF/context.xml and not in 
conf/server.xml. Yes, you can put it in server.xml, but you should not 
do that for a few reasons.



   


Yuck. Now you have an application deployed into "/ROOT" as well as "" 
(the default ROOT application, mounted on /)



This achieves the objective of making "foo" the default so now I can just
use localhost:8080/HelloWorld.jsp


I think you must have copy/pasted incorrectly, but nothing of what you 
put above would allow /HelloWorld.jsp to run the JSP in "foo".



However "allow linking" is silently ignored.  I also tried editing
context.xml and adding to the context:

  
   


This ... is confusing at best because you have two elements in there. 
I'm not sure what will happen if you define it twice. Maybe the second 
one overwrites the first? If that's true, it might explain why it 
wouldn't work.



Both of these solutions were gleaned from reading the documentation and
Google searches, and I seem to be stuck here.

For now I cannot install a later version of Tomcat (using Amazon Java 8
Coretto) or remove the symlinks as they are required by an existing
application.

Any thoughts are greatly appreciated.


First: simplify. Put everything into your application and give it the 
name AND context-path you want, for example webapps/foo and everything 
is in there.


There is really only one place where symlinking can be configured at 
all, which is . Put your  in 
webapps/foo/META-INF/context.xml and use a single  element 
with an appropriate configuration.


Remove everything else.

Restart and see what happens when you request /foo/Link.jsp

-chris

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

Re: Tomcat MySQL Connection Pooling JNDI lookup

Daniel,

On 6/19/24 11:40, Daniel Schwartz wrote:

Dear Felix,

Thank you for your reply. The connector jar file is at

C:\Program Files\apache-tomcat-10.1.24\lib\mysql-connector-j-8.4.0.jar

The latest entry in catalina.2024-06-17.log is copied below. The latest entry
in localhost.2024-06-17.log is copied after that. The two entries are
essentially identical.

The cause of the failure is reported as

Caused by: java.lang.NullPointerException: Cannot invoke
"javax.sql.DataSource.getConnection()" because "this.dataSource" is null
at
com.worldholidaysandevents.restjsonwebservice.HolidaysRestJsonWebServiceResource.getJsonCountries(HolidaysRestJsonWebServiceResource.java:56)

However, this is turn is caused by the failure reported in my previous email on
the line

dataSource = (DataSource) ctx.lookup("jdbc/holidays");

in a file called DataSourceSingleton.java, which is invoked by the
getJsonCountries method. The method is supposed to extract a list of countries
from the database, but the list is returned as null since the JNDI lookup
fails. I identified this failure by putting print statements immediately
before and after this line. The statement before the line outputs its message,
and the one after this line does not. You can see this in the Command Prompt
where Tomcat is running. I copied this error message in my previous email.

Your code looks fine. Fully-specifying the JNDI URL is basically
optional, but it wouldn't hurt.

I would move that context.xml file into your application under
META-INF/context.xml and restore the original conf/context.xml because
you do not need that JNDI resource to be made available to every
application on your server (right?).

I would also recommend NOT using the "root" user for your database
connection. I realize that you are probably "just getting started" but
it would be best to use an application-specific user for your database,
and to get into that habit as soon as possible.

catalina.2024-06-17.log:
---

17-Jun-2024 15:43:06.184 SEVERE [http-nio-8080-exec-1]
org.glassfish.jersey.server.ServerRuntime$Responder.writeResponse Error while
closing the output stream in order to commit response.
org.glassfish.jersey.server.ContainerException: java.util.concurrent.ExecutionException:
java.lang.NullPointerException: Cannot invoke "javax.sql.DataSource.getConnection()"
because "this.dataSource" is null

Are there any other errors you can see in any log file?

Usually, Tomcat will emit an error if the JNDI resource cannot be created.

-chris

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

Re: Tomcat MySQL Connection Pooling JNDI lookup


Daniel,

On 6/19/24 11:09, Daniel Schwartz wrote:

Dear Thomas,

  


Your email came with no content.  Please try again.


His reply email looks fine to me.

-chris


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

Re: Configuration of Certificate Verification on Tomcat 10