from:"christopher"

Izek,

On 10/22/24 15:05, Izek Hornbeck wrote:
Right now we are only using HTTP/1.1--do you think that could make a 
difference?

Only in that is reduces the number of places in Tomcat where a 400 
response is sent.

I would say it is reproducible... as far as I can recall, I see this at 
least the first time in a day that I access each application deployed on 
tomcat, and some other times during the day after that. For example, say 
I navigate to "applicationA" first thing in the morning--most likely, 
the login page comes up but is obviously missing some images and the css 
file. (I can see in my browser dev tools and the tomcat logs that those 
resources were not obtained, with a 400 response.) If I login to the 
application without refreshing the login page, the next page typically 
is also missing images and/or css files. If I refresh before logging in, 
the login page often gets most/all of the missing resources as does the 
next page. Some days, it takes a few refreshes, or even a tomcat 
restart, to get all the resources loaded--it typically gets worse as 
more time passes since the last restart. With that, it makes me think 
that something is assumed to be cached, but it is not?

If you can reproduce it, try enabling the request dumper valve.

You should only do this in a dev/test environment. It will fill your log 
file with 99% of the HTTP conversation on both the client and server 
end. Reproduce the issue (400 in the access log) then find the 
corresponding request in the application log (where the dumper will 
dump) and look at:

1. The inbound headers
2. The HTTP response line which may have more detail than just "400"

-chris

On Tue, Oct 22, 2024 at 11:04 AM Christopher Schultz 
mailto:ch...@christopherschultz.net>> wrote:

Izek,

On 10/16/24 18:07, Izek Hornbeck wrote:
 > I have confirmed that our development team has seen these same
loading
 > issues with Tomcat 9.0.55 and 9.0.86.

Are you using HTTP/2 or AJP at all? Or only HTTP/1.1?

Is it at all reprodicible or are you just looking at log files?

It's definitely possible for a client to provide e.g. bogus HTTP
headers
which would cause a 400 response even though the request was for a
static file.

-chris

 > On Wed, Oct 16, 2024 at 3:22 PM Izek Hornbeck
mailto:izekhornb...@gmail.com>>
 > wrote:
 >
 >> We are working on a large upgrade for this application, so we
are looking
 >> at upgrading Tomcat too (either to version 10 if we can resolve the
 >> javax/jakarta issues or just to the current 9.0.x). I'll try
some tests
 >> locally to see what impact newer versions could have.
 >>
 >> In the access logs, we occasionally get lines like this:
 >>
 >> XXX.YYY.ZZZ.AA - - [15/Oct/2024:10:08:20 -0600] "GET
 >> /app_name/some_page.jsp HTTP/1.1" 200 16107
 >> XXX.YYY.ZZZ.AA - - [15/Oct/2024:10:08:20 -0600] "GET
 >> /app_name/styles/some_style.css HTTP/1.1" 400 762
 >> XXX.YYY.ZZZ.AA - - [15/Oct/2024:10:08:20 -0600] "GET
 >> /app_name/styles/some_other_style.css HTTP/1.1" 400 762
 >> XXX.YYY.ZZZ.AA - - [15/Oct/2024:10:08:20 -0600] "GET
 >> /app_name/dwr/interface/some_script.js HTTP/1.1" 200 13339
 >> XXX.YYY.ZZZ.AA - - [15/Oct/2024:10:08:21 -0600] "GET
 >> /app_name/javascript/dashboard.js HTTP/1.1" 200 21841
 >>
 >> Sometimes there are .jpg files that also have a 400 response. The
 >> confusing part is that those files don't always get that
response, and it's
 >> not always the same files.
 >>
 >> -Izek
 >>
 >> On Mon, Oct 14, 2024 at 9:32 AM Chuck Caldarale
mailto:n82...@gmail.com>> wrote:
 >>
 >>>
 >>>> On Oct 11, 2024, at 12:48, Izek Hornbeck
mailto:izekhornb...@gmail.com>>
 >>> wrote:
 >>>>
 >>>> My team has a Java web app (java v17.0.2) running on a Tomcat
9.0.40
 >>>> server.
 >>>
 >>>
 >>> Which is almost 4 years old. You really, really need to catch up.
 >>>
 >>>
 >>>> When we upgraded to Tomcat 9, we found that occasionally, some css
 >>>> files and images would not load, with a 400 response. They
would appear
 >>>> after a page refresh (sometimes I had to refresh twice).
 >>>>
 >>>> The closest thing I've found about issues like this is
 >>>>
 >>> https://stackoverflow.com/questions/77989064/intermittently-
getting-status-400-for-js-css-images-after-upgrading-to-tomcat-9
<htt

Re: Help with tomcat 11 failure


Chuck,

On 10/21/24 14:06, Chuck Caldarale wrote:



On Oct 21, 2024, at 12:19,  
 wrote:

Fellow user here.

I am guessing that you need to migrate your application to Java 17+ and make 
all the necessary changes to move from the javax.* to the Jakarta EE jakarta.* 
packages.  This includes all servlet stuff.



Yes, Tomcat 11 requires Java 17 or later; see:
https://tomcat.apache.org/whichversion.html


You may well need to update your servlet / JSP code for the reasons specified 
on the Tomcat 11 download page:
Users of Tomcat 11 onwards should be aware that, as a result of the move from Java EE 
to Jakarta EE as part of the transfer of Java EE to the Eclipse Foundation, the 
primary package for all implemented APIs has changed from javax.* to jakarta.*. This 
will almost certainly require code changes to enable applications to migrate from 
Tomcat 9 and earlier to Tomcat 11 and later. A migration tool 
 has been developed to 
aid this process.

For migrating your code, you can use this:
https://tomcat.apache.org/download-migration.cgi


You may also want to look at this for specific migration information:
https://tomcat.apache.org/migration.html


+1

... and also you should be able to drop your WAR file into 
$CATALINA_BASE/webapps-javaee and get it automagically migrated.


-chris


Cheers, Jeff

On Oct 21, 2024 6:57 PM, Jim Anderson  wrote:
Hi,

I was working on a web application about 2 years ago and I am finally getting 
back to my work on this application. However, when I try to bring up the app as 
a web page in firefox, tomcat is failing with a stack trace which I am 
attaching to this email.

Looking at the stack trace, I see that the class:
 javax.servlet.jsp.tagext.TagLibraryValidator
was not found.

My questions is: Where is the TagLibraryValidator class to be found?

Jim Anderson







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

Re: Can't access servlet 404 advise requested


Holger,

On 10/19/24 04:02, Holger Klawitter wrote:

you Servlet is not connected to any url.
You need a servlet mapping with a url-pattern
specifyng which url to reply to.


+1

-chris


Frank Myers wrote (at 2024-10-18 21:05 +):

Chris,

I use "http://9.114.12.58:8080/WHMerge/";
Web.xml (in the war file) contains

http://www.w3.org/2001/XMLSchema-instance"; xmlns="https://jakarta.ee/xml/ns/jakartaee"; 
xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee https://jakarta.ee/xml/ns/jakartaee/web-app_5_0.xsd"; 
id="WebApp_ID" version="5.0">
  WHMerge
  
   WHMerge
   com.ibm.wca4z.webhooks.WHMerge
  



With kindest regards,

Frank Myers



From: Christopher Schultz 
Sent: Friday, October 18, 2024 11:53 AM
To: users@tomcat.apache.org 
Subject: [EXTERNAL] Re: Can't access servlet 404 advise requested

Frank,

On 10/17/24 10:09 AM, Frank Myers wrote:

I see in the catalina log:
17-Oct-2024 13:57:11.194 INFO [http-nio-8080-exec-30] 
org.apache.catalina.core.StandardContext.reload Reloading Context with name 
[/WHMerge] has started
17-Oct-2024 13:57:11.196 WARNING [http-nio-8080-exec-30] 
org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesObjectStreamClassCaches
 Failed to clear soft references from ObjectStreamClass$Caches for web 
application [WHMerge]
  java.lang.ClassCastException: class 
java.io.ObjectStreamClass$Caches$1 cannot be cast to class java.util.Map 
(java.io.ObjectStreamClass$Caches$1 and java.util.Map are in module java.base 
of loader 'bootstrap')
  at 
org.apache.catalina.loader.WebappClassLoaderBase.clearCache(WebappClassLoaderBase.java:2325)
  at 
org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesObjectStreamClassCaches(WebappClassLoaderBase.java:2300)
  at 
org.apache.catalina.loader.WebappClassLoaderBase.clearReferences(WebappClassLoaderBase.java:1669)
  at 
org.apache.catalina.loader.WebappClassLoaderBase.stop(WebappClassLoaderBase.java:1597)
  at 
org.apache.catalina.loader.WebappLoader.stopInternal(WebappLoader.java:463)
  at 
org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:257)
  at 
org.apache.catalina.core.StandardContext.stopInternal(StandardContext.java:5515)
  at 
org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:257)
  at 
org.apache.catalina.core.StandardContext.reload(StandardContext.java:3811)
  at 
org.apache.catalina.manager.ManagerServlet.reload(ManagerServlet.java:1132)
  at 
org.apache.catalina.manager.HTMLManagerServlet.reload(HTMLManagerServlet.java:644)
  at 
org.apache.catalina.manager.HTMLManagerServlet.doPost(HTMLManagerServlet.java:215)
  at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:681)
  at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:764)
  at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:227)
  at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
  at 
org.apache.catalina.filters.CsrfPreventionFilter.doFilter(CsrfPreventionFilter.java:211)
  at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
  at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
  at 
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
  at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
  at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
  at 
org.apache.catalina.filters.HttpHeaderSecurityFilter.doFilter(HttpHeaderSecurityFilter.java:126)
  at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
  at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
  at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:197)
  at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:97)
  at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:659)
  at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:135)
  at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
  at 
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:687)
  at 
org.apache.catalina.core.Sta

Re: Occasional 400 errors for static resources in Tomcat 9.0.40


Izek,

On 10/16/24 18:07, Izek Hornbeck wrote:

I have confirmed that our development team has seen these same loading
issues with Tomcat 9.0.55 and 9.0.86.


Are you using HTTP/2 or AJP at all? Or only HTTP/1.1?

Is it at all reprodicible or are you just looking at log files?

It's definitely possible for a client to provide e.g. bogus HTTP headers 
which would cause a 400 response even though the request was for a 
static file.


-chris


On Wed, Oct 16, 2024 at 3:22 PM Izek Hornbeck 
wrote:


We are working on a large upgrade for this application, so we are looking
at upgrading Tomcat too (either to version 10 if we can resolve the
javax/jakarta issues or just to the current 9.0.x). I'll try some tests
locally to see what impact newer versions could have.

In the access logs, we occasionally get lines like this:

XXX.YYY.ZZZ.AA - - [15/Oct/2024:10:08:20 -0600] "GET
/app_name/some_page.jsp HTTP/1.1" 200 16107
XXX.YYY.ZZZ.AA - - [15/Oct/2024:10:08:20 -0600] "GET
/app_name/styles/some_style.css HTTP/1.1" 400 762
XXX.YYY.ZZZ.AA - - [15/Oct/2024:10:08:20 -0600] "GET
/app_name/styles/some_other_style.css HTTP/1.1" 400 762
XXX.YYY.ZZZ.AA - - [15/Oct/2024:10:08:20 -0600] "GET
/app_name/dwr/interface/some_script.js HTTP/1.1" 200 13339
XXX.YYY.ZZZ.AA - - [15/Oct/2024:10:08:21 -0600] "GET
/app_name/javascript/dashboard.js HTTP/1.1" 200 21841

Sometimes there are .jpg files that also have a 400 response. The
confusing part is that those files don't always get that response, and it's
not always the same files.

-Izek

On Mon, Oct 14, 2024 at 9:32 AM Chuck Caldarale  wrote:




On Oct 11, 2024, at 12:48, Izek Hornbeck 

wrote:


My team has a Java web app (java v17.0.2) running on a Tomcat 9.0.40
server.



Which is almost 4 years old. You really, really need to catch up.



When we upgraded to Tomcat 9, we found that occasionally, some css
files and images would not load, with a 400 response. They would appear
after a page refresh (sometimes I had to refresh twice).

The closest thing I've found about issues like this is


https://stackoverflow.com/questions/77989064/intermittently-getting-status-400-for-js-css-images-after-upgrading-to-tomcat-9
.


We have just recently tried adding "cachingAllowed=false" to the
"tomcat/conf/context.xml" file, but it hasn't been long enough to know

if

that really fixed the issue.

Has anyone had a similar issue? What might be the root cause?



Without any real data (eg, access logs), there’s no way to answer that
question. Your first step should be to upgrade to the current 9.0.x version.

   -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: Tomcat 10.1 STIGing

2024-10-29 Thread Christopher Schultz


Mark,

On 10/29/24 04:03, Mark Thomas wrote:

On 28/10/2024 21:44, Leroy Mims wrote:
My place of work prefers DISA STIGed software. I contacted DISA about 
STIGs

for Tomcat 10.1 and they said that the organization that produces the
software has to request that it be STIGed. The idea of applyingTomcat 9
STIGs to Tomcat 10.1 was rejected and DISA STIGs are preferable to CIS
Benchmarks.
Thank you.
Leroy Mims


I am not aware of any plans for the Tomcat team to request a STIG 
assessment for Tomcat 10. Should such a proposal be made, I would argue 
strongly NOT to make such a request.


-0

I kinda feel like if they want to write another guide that doesn't 
provide any security, they can go ahead. I don't know why "the vendor" 
needs to make a request. We certainly didn't make a request for Tomcat 9 
that I can recall and yet it seems to exist.


My personal recommendation is to avoid the STIG recommendations at all 
costs. The last time I reviewed the latest STIG for Tomcat it contained 
a large amount of utter nonsense. I've just looked up the latest 
recommendations (2024-05-23) for Tomcat 9 and it still contains this 
howler:


https://www.stigviewer.com/stig/ 
apache_tomcat_application_server_9/2024-05-23/finding/V-222950


That such a finding was written, reviewed and approved gives me zero 
confidence in the entire STIG process.


+1


We started a community review of the previous Tomcat 9 STIG:

https://cwiki.apache.org/confluence/display/TOMCAT/ 
Community+Review+of+DISA+STIG


I lost interest after the first half-dozen or so issues due to the sheer 
volume of problems I was finding and that no-one else seemed interested 
in either contributing or in the results.


Same here. After a while it just turned into reading "security controls" 
that didn't provide any security and/or completely misunderstood the 
settings. It seemed to miss a lot of things I would have in a decent 
runbook.


The CIS benchmarks appear to be of better quality but they still contain 
some issues such as not fully accounting for the correct secure 
connector settings when running Tomcat behind a reverse proxy.


I did reach out to the CIS benchmark folks to point out some of the 
errors I found but their response was rather disappointing. It was - 
essentially - join our review team and provide all the corrections for 
free (so we can then sell benchmark to commercial customers).


I don't mind contributing to community resources - I wouldn't be 
contributing to open source if I did - but I do object to being asked to 
provide my time at zero cost to support someone else's commercial product.


I 100% agree with this. We are happy to provide community support, but 
I'm not going to work for free for a commercial company to sell my work.


What I do recommend is start with the security how-to in the Tomcat docs 
and then ask any questions you have here.


While I agree with this, it's not going to make Leroy's employer any 
happier. They want a DISA STIG, they're gonna demand a DISA STIG.


-chris


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

Re: pluggabilitySkip JarScanFilter and JMX calls

2024-11-04 Thread Christopher Schultz


Amit,

On 11/3/24 22:48, Amit Pande wrote:

Thank you, Chris, for quick response.

I am trying to play with the scan/skip values.

https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/context/event/EventListener.html
Does this @EventListener Spring annotation get affected by this 
pluggabilitySkip setting?


I believe if you disable jar scanning, then Tomcat will ignore all 
annotations for things like Listeners that should be running on startup.


-chris


-Original Message-
From: Christopher Schultz 
Sent: Sunday, November 3, 2024 3:39 PM
To: Tomcat Users List 
Subject: Re: pluggabilitySkip JarScanFilter and JMX calls


CAUTION: This email originated from outside the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe. If you believe this is a phishing email, use the Report to 
Cybersecurity icon in Outlook.



Amit,

On 11/3/24 11:56 AM, Amit Pande wrote:

Hello,

I have been experimenting with the JarScanFilter setting to boost the 
application deployment time.

 
  
  

When I add this:
JarScanFilter pluggabilitySkip="*.jar"

The JMX calls stopped working. E.g. I am seeing:

javax.management.InstanceNotFoundException: 
Catalina_Web_Services:j2eeType=WebModule,name=//localhost/mywebapp,J2EEApplication=none,J2EEServer=none
  at 
java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(Unknown
 Source) ~[?:?]
  at 
java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(Unknown
 Source) ~[?:?]
  at 
java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(Unknown 
Source) ~[?:?]
  at com.myapp.findMBeanState(MyTest.java:124) ~[myapp.jar:?]

Am I missing some additional configuration?

Appreciate the help.


The JarScanner does more than it looks like it does. I'm guessing that you have 
a component that uses something like annotation-based 
SomethingSomethingListener and that component is not being found and 
initialized when the application starts.

That component probably registers your MBean with the local JMX server.

Try being more restrictive with your pluggability-skipping. You might want to search all 
your JAR files for "*Listener.class" and let those JARs continue to be 
processed.

-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: pluggabilitySkip JarScanFilter and JMX calls

2024-11-03 Thread Christopher Schultz


Amit,

On 11/3/24 11:56 AM, Amit Pande wrote:

Hello,

I have been experimenting with the JarScanFilter setting to boost the 
application deployment time.


 
 

When I add this:
JarScanFilter pluggabilitySkip="*.jar"

The JMX calls stopped working. E.g. I am seeing:

javax.management.InstanceNotFoundException: 
Catalina_Web_Services:j2eeType=WebModule,name=//localhost/mywebapp,J2EEApplication=none,J2EEServer=none
 at 
java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(Unknown
 Source) ~[?:?]
 at 
java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(Unknown
 Source) ~[?:?]
 at 
java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(Unknown 
Source) ~[?:?]
 at com.myapp.findMBeanState(MyTest.java:124) ~[myapp.jar:?]

Am I missing some additional configuration?

Appreciate the help.


The JarScanner does more than it looks like it does. I'm guessing that 
you have a component that uses something like annotation-based 
SomethingSomethingListener and that component is not being found and 
initialized when the application starts.


That component probably registers your MBean with the local JMX server.

Try being more restrictive with your pluggability-skipping. You might 
want to search all your JAR files for "*Listener.class" and let those 
JARs continue to be processed.


-chris


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

Re: Fwd: NoClassDefFoundError: javax/mail/Authenticator


Mark,

On 10/24/24 13:10, Mark Thomas wrote:

On 24/10/2024 17:07, Alan Masters wrote:
I am attempting to send e-mail from Tomcat using an external mail host 
-    mail.btinternet.com.


I have included javax.mail jar in my build path and can see 
javax.mail.Authenticator in this library.


When trying to start up  apache-tomcat-9.0.91 I get 
IllegalStateException: Error starting child


    Caused by: java.lang.NoClassDefFoundError: javax/mail/Authenticator

any help would be appreciated please.


Could we see the full stack trace?

Have you included it in your web application? If so, where?


+1

Use of the term "build path" makes me think that the IDE is happy, but 
the deployment is not.


-chris


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

Re: [OT] javax.naming.NameNotFoundException


Mark F,

On 10/23/24 18:13, Mark Foley wrote:

On Wed, 23 Oct 2024 19:13:44 Mark Thomas  wrote:


On 23/10/2024 18:57, Mark Foley wrote:

I'm running Tomcat 8.5.11. I have a hopefully small problem.


Tomcat 8.5.x is EOL and no longer supported.

8.5.11 is also rather old with quite a long list of know security issues.


Yeah, I know. Updating it is on my todo list. I'm running 10.1.13 elsewhere, but
I have a lot of changes to make getting to 10.x.x so I've been kicking that can
down the road. I was hoping this particular issue wasn't dependent on version.


Tomcat 9 should work just fine for you.

-chris


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

Re: javax.naming.NameNotFoundException


Mark F,

On 10/23/24 18:13, Mark Foley wrote:

On Wed, 23 Oct 2024 19:13:44 Mark Thomas  wrote:


On 23/10/2024 18:57, Mark Foley wrote:

I'm running Tomcat 8.5.11. I have a hopefully small problem.


Tomcat 8.5.x is EOL and no longer supported.

8.5.11 is also rather old with quite a long list of know security issues.


Yeah, I know. Updating it is on my todo list. I'm running 10.1.13 elsewhere, but
I have a lot of changes to make getting to 10.x.x so I've been kicking that can
down the road. I was hoping this particular issue wasn't dependent on version.


I have a webapp directory: $CATALINA_HOME/webapps/myapp/. In that directory I 
have WEB-INF/web.xml with:


connURL
jdbc:mysql://localhost/members?
java.lang.String


In this example, the env-entry is just part of an SQL connection string I want 
to snag.

In a browser, going to: /myapp/index.jsp works fine with WEB-INF as shown 
above.

What I want to do is put all of this in a sub-directory: 
$CATALINA_HOME/webapps/myapp/subapp/ and access it on my browser as 
/myapp/subapp/index.jsp. When I do that -- no changes to anything -- I 
get the error:


That won't work. What will work is renaming:

$CATALINA_HOME/webapps/myapp

to

$CATALINA_HOME/webapps/myapp#subapp/

Mark


Hmmm ... what I was attempting was splitting many webapps into multiple
directories.


What is the real goal, here?

Do they have to be separate web applications? If so, why? 
Security/isolation? Easy of deployment? Separate configuration(s)?


Deploying many web applications isn't a problem unless you are very 
resource constrained (e.g. RAM).


-chris


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

[ANN] Apache Tomcat 10.1.33 Available

2024-11-11 Thread Christopher Schultz


The Apache Tomcat team announces the immediate availability of Apache
Tomcat 10.1.33.

Apache Tomcat 10 is an open source software implementation of the
Jakarta Servlet, Jakarta Pages, Jakarta Expression Language,
Jakarta WebSocket, Jakarta Authentication and Jakarta Annotations
specifications.

Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 
without changes. Java EE applications designed for Tomcat 9 and earlier 
may be placed in the /webapps-javaee directory and Tomcat will 
automatically convert them to Jakarta EE and copy them to the webapps 
directory. This conversion is performed using the Apache Tomcat 
migration tool for Jakarta EE tool which is also available as a separate 
download for off-line use.


Apache Tomcat 10.1.33 is a bugfix and feature release. The notable 
changes compared to 10.1.31 include:


 - Fix a regression caused by the improvement 69333 which caused the
  tag release to be called when using tag pooling, and to be skipped
  when not using it. Patch submitted by Michal Sobkiewicz.
 - Further WebDAV fixes and improvements.

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-10.1-doc/changelog.html

Downloads:
http://tomcat.apache.org/download-10.cgi

Migration guides from Apache Tomcat 8.5.x and 9.0.x:
http://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team


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

Re: IndexOutOfBoundsException at getHeader with tomcat9.0.87


Shanghe,

On 10/22/24 22:59, shanghe chen wrote:

Sorry the link is 
https://github.com/apache/tomcat/pull/551
 it seems malformed in last post

发件人: shanghe chen 
发送时间: Wednesday, October 23, 2024 10:50:48 AM
收件人: users@tomcat.apache.org 
主题: IndexOutOfBoundsException at getHeader with tomcat9.0.87

Hi using tomcat 9.0.87, occasionally I got the following exception:

java.lang.IndexOutOfBoundsException
   at java.base/java.nio.ByteBuffer.wrap(ByteBuffer.java:438
   at org.apache.tomcat.util.buf.ByteChunk.toStringInternal(ByteChunk.java:622)
   at org.apache.tomcat.util.buf.StringCache.toString(StringCache.java:323)
   at org.apache.tomcat.util.buf.ByteChunk.toString(ByteChunk.java:580)
   at org.apache.tomcat.util.buf.ByteChunk.toString(ByteChunk.java:565)
   at org.apache.tomcat.util.buf.MessageBytes.toString(MessageBytes.java:173)
   at org.apache.tomcat.util.http.MimeHeaders.getHeader(MimeHeaders.java:355)
   at org.apache.coyote.Request.getHeader(Request.java:468)

when invoking the getHeader method. For lacking of the context, I cannot get 
the concrete header now and it seems quite hard to reproduce.

  I'm wondering if anyone has encountered the same issue before? is the 
MessageBytes malformed? I got a kind of related issue 
https://github.com/apache/tomcat/pull/551but not sure if it's relavent since 
it's involved in version 9.0.66.


Can you post the complete stack trace?

If you must remove your own code from the stack trace, that's fine. But 
it would be good to see all of the Tomcat-related calls.


-chris


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

Re: deploying on 9.0.96 is painful


Ronald,

On 10/24/24 10:31, Ronald Klop wrote:

Van: "Rémy Maucherat" 
Datum: woensdag, 23 oktober 2024 17:48
Aan: users@tomcat.apache.org
Onderwerp: Re: deploying on 9.0.96 is painful


On Wed, Oct 23, 2024 at 5:37PM Ronald Klop
 wrote:
>
> Hi,
>
> We pre-compile our JSPs. Team Dev uses Tomcat jars for this. And 
team Sys keeps the Tomcat servers running and up-to-date.

> Running Tomcat since 5.x or maybe even before. Currently running 9.0.x.
>
> For years it worked fine if we kept the jars versions of team Dev 
close to the Tomcat server version of team Sys. It was very efficient 
because versions didn't need to be exactly the same. And we could test 
versions without doing a turn-key deploy. Occasional rollback of a 
deploy was also possible, although the JSPs were not compiled with the 
exact same jar versions.

>
> Tomcat 9.0.96 was very painful in this regard. We found the reason 
for it in https://lists.apache.org/ 
thread/62j98og8xn9p9ovxxj6bfqht85xg2qgz.
> 9.0.96 JSPs didn't work on 9.0.95 and 9.0.95 JSPs didn't work on 
9.0.96 Tomcat. (I didn't check this personally, but trust my colleague 
in it.)
> Deploy needed to be turn-key with synchronization between teams on 
multiple clusters of servers.

>
> I'm not here to rant about it. Things can break.
> But I didn't find any information about solutions on the website/ML.
> We couldn't be sure that 9.0.97 would have a fix or just have the 
same incompatibility so decided to push through with 9.0.96.

>
> Anyways, I thought it is good to give some feedback about the issue 
as a user of the product.

>
> I think it would have been nice to have a statement about 9.0.96 and 
pre-compiled JSPs and how future versions would handle this situation.

>
> If I missed this statement on the website or in the ML archives than 
I will happily stand corrected. :-)

>
> And now we go further with development and hope that future releases 
will be as easy as they were before.


It's not possible to guarantee never having to recompile due to having
to do fixes in the generated code (this should be rather obvious).
However in this case it was easy to keep compatibility so it was fixed
and the fix will be in 9.0.97.

Rémy

> Regards,
> Ronald.
> Â

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







Thanks for the response and the confirmation that it will be handled 
better in 9.0.97.


I've added an entry in the Tomcat 9.0.x Migration Guide's "Noteable 
Changes" section about this issue.


https://tomcat.apache.org/migration-9.html#Upgrading_9.0.x

-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: 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 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: 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: 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: 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: 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: [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: 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/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: 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: Tomcat 10.1.30 and Many Timed Waiting threads

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

2024-10-01 Thread Christopher Schultz


Michael,

On 10/1/24 12:13, Michael Osipov wrote:

On 2024/10/01 13:56:22 Christopher Schultz wrote:

Michael,

On 10/1/24 05:21, Michael Osipov wrote:

On 2024/09/30 17:21:30 Christopher Schultz wrote:

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.


I am aware of that, but Digest is dead, at least via SASL. Unfortunately RFC 
7804 never gained traction in this regard.


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.


Yes, unfortunately. They never and will never care about non-AD users.


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.


As said, all requires SPNEGO. WebDAV for Windows Explorer just works with 
SPNEGO and nothing else. You still can use a KDC like Samba to achieve the 
above without losing the LDAP bind-based authentication, but OpenLDAP will 
handle over to a KDC.


I'd be interested to see some references for getting SPNEGO to work with
httpd mod_dav and OpenLDAP as a back-end. If it can expose Kerberos to
clients, I'll gladly give it a shot.


Here you go: https://lists.apache.org/thread/dnmrcgq5f1txsf7shh3dq7m044bdkv4k> 
Now you need to use mod_authnz_ldap as authorization provider.


I'm already using mod_authnz_ldap. AuthType GSSAPI looks like it 
requires a third-party module and, possibly, a Kerberos 
"implementation". It looks like my Debian-based system has a package 
"libapache2-mod-auth-gssapi" which has a dependency on 
"libgssapi-krb5-2". Is that essentially all I need?


Is there an equivalent of "AuthBasicProvider ldap" that I would need 
with gssapi to make it use the ldap provider?


The Kerberos principal needs to be mapped to an LDAP attribute, 
dependening on the system it could be userPrincipal or 
krb5Principal. Give it a shot, if you have the setup.

I'll see what I can do. Thanks for the pointer.


On Tomcat side I have replaced LDAP authz with something much better/
faster for most of the use cases.

There is no Tomcat in this particular environment. Just httpd and a disk.

-chris


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

Re: Using HTTP 1.1 over a configured HTTP2 Connector

2024-10-01 Thread Christopher Schultz


Mark and Anurag,

On 10/1/24 08:38, Mark Thomas wrote:

On 01/10/2024 06:15, Anurag Sharma wrote:

Dear Tomcat Team,

I hope this message finds you well.

I am currently facing a challenge regarding the use of HTTP/1.1 for 
specific API endpoints within a servlet configured for HTTP/2. My 
browser defaults to HTTP/2, which complicates the situation as I need 
to proxy some APIs to a server that only supports HTTP/1.1.
Is there a workaround available to enforce HTTP/1.1 for these 
particular endpoints?


It isn't clear from the above which component needs to talk to which 
using what protocol.


Servlets don't care whether the request is received via HTTP/1.1 or HTTP/2.

Tomcat will happily process requests for the same servlet using HTTP/1.1 
or HTTP/2 depending on client support.


Outgoing requests from Tomcat to external services are outside of the 
control of Tomcat and are entirely an application concern.


Can you be more precise about what the problem is?


Also... where is the proxy? Out in front of Tomcat, or is your 
application acting as the proxy?


-chris


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

Re: [OT] accessing manager app

2024-10-01 Thread Christopher Schultz


Michael,

On 10/1/24 05:21, Michael Osipov wrote:

On 2024/09/30 17:21:30 Christopher Schultz wrote:

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.


I am aware of that, but Digest is dead, at least via SASL. Unfortunately RFC 
7804 never gained traction in this regard.


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.


Yes, unfortunately. They never and will never care about non-AD users.


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.


As said, all requires SPNEGO. WebDAV for Windows Explorer just works with 
SPNEGO and nothing else. You still can use a KDC like Samba to achieve the 
above without losing the LDAP bind-based authentication, but OpenLDAP will 
handle over to a KDC.


I'd be interested to see some references for getting SPNEGO to work with 
httpd mod_dav and OpenLDAP as a back-end. If it can expose Kerberos to 
clients, I'll gladly give it a shot.



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.


...there is no need, as said you can use Samba as a decent identity provider or 
MIT Kerberos paired with an OpenLDAP backend. Both do work, both are open 
source. No IaaS required.


I don't intend to introduce Samba as a component if I can help it.

-chris


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

Re: Considerations for the WebDAV servlet

2024-10-02 Thread Christopher Schultz


Michael,

On 10/1/24 12:14, Michael Osipov wrote:

On 2024/10/01 15:20:53 Rémy Maucherat wrote:

On Tue, Oct 1, 2024 at 4:53 PM Michael Osipov  wrote:


Folks,

I'd like to put some effort into the DefaultServlet and the WebDAV servlet
to align them more with mod_autoindex and add some minor improvements if I
can cover my usecases here at work.

Currently, I use mod_dav which I want to replace with the WebDAV servlet
because I don't have the authz components in HTTPd like I have in Tomcat
(it is rather a pain since I need to sync groups into a local file).

The config in HTTPd is straight forward:


 ProxyPassMatch "!"


AliasMatch "^/(backend-dev|content-dev|prod)/dav(/|$)(.*)" "/var/foo/$1$2$3"

 Dav On
 AuthType GSSAPI
 AuthName "Foo WebDAV Repository"
 AuthzSendForbiddenOnFailure On
 Options Indexes
 IndexOptions FancyIndexing FoldersFirst Charset=UTF-8 NameWidth=* 
SuppressDescription
 
 AuthGroupFile /var/foo/db/apache-groups.txt
 Require group foo-maintainers bar-maintainers baz-maintainers
 
 AddDefaultCharset utf-8
 AddType text/plain .log .tex



/(backend-dev|content-dev|prod) are proxied to three Tomcat instances, the
config above would be replaced with subcontexts at 
/(backend-dev|content-dev|prod)#dav
(solely for the DAV purpose) where the web.xml contains:


   webdav
   org.apache.catalina.servlets.WebdavServlet
   
   listings
   true
   
   
   showServerInfo
   false
   
   
   sortListings
   true
   
   
   sortDirectoriesFirst
   true
   
   
   fileEncoding
   UTF-8
   
   1



   webdav
   /*


   
   
   WebDAV
   /*
   
   
   Foo Maintainer
   Bar Maintainer
   Baz Maintainer
   
   


and the context.xml (for backend-dev):



   

   

   

   
   
   



It just works from the browser, CarotDAV, the Windows Explorer, and 
py-webdavclient3.

Now my question/concern is the Javadoc of the servlet [1] says:

The WebDAVServlet must not be used as the default servlet (ie mapped to '/') as 
it will not work in this configuration.


Well, it works, doesn't it? And the sample below maps to root as well:

   
 webdav
 /*
   


So what is it now, can I safely use the servlet with this setup?
There is nothing else in this WAR file except context.xml, web.xml and
a properties file.


/* mapping is very different from /. / is the default servlet. /* is
not and has a priority over it.
The javadoc which you linked to has a mapping example of the WebDAV
servlet using /*, which is 100% ok.


Ahhh, you are right. It is a subtile difference. I want to evalute yet another 
option depicted in the DefaultServlet Javadoc, but in any case it looks good so 
far.


IMHO It's worth pointing out in this same place in the documentation 
that "/ is bad but /* is okay". When I read your question I thought "/ 
!= /*" but not every user would understand the distinction.


-chris


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

Re: [OT] accessing manager app

2024-10-02 Thread Christopher Schultz




Michael,

On 10/1/24 15:27, Michael Osipov wrote:


On 2024/10/01 17:12:55 Christopher Schultz wrote:

Michael,

On 10/1/24 12:13, Michael Osipov wrote:

On 2024/10/01 13:56:22 Christopher Schultz wrote:

Michael,

On 10/1/24 05:21, Michael Osipov wrote:

On 2024/09/30 17:21:30 Christopher Schultz wrote:

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.


I am aware of that, but Digest is dead, at least via SASL. Unfortunately RFC 
7804 never gained traction in this regard.


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.


Yes, unfortunately. They never and will never care about non-AD users.


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.


As said, all requires SPNEGO. WebDAV for Windows Explorer just works with 
SPNEGO and nothing else. You still can use a KDC like Samba to achieve the 
above without losing the LDAP bind-based authentication, but OpenLDAP will 
handle over to a KDC.


I'd be interested to see some references for getting SPNEGO to work with
httpd mod_dav and OpenLDAP as a back-end. If it can expose Kerberos to
clients, I'll gladly give it a shot.


Here you go: https://lists.apache.org/thread/dnmrcgq5f1txsf7shh3dq7m044bdkv4k> 
Now you need to use mod_authnz_ldap as authorization provider.


I'm already using mod_authnz_ldap. AuthType GSSAPI looks like it
requires a third-party module and, possibly, a Kerberos
"implementation". It looks like my Debian-based system has a package
"libapache2-mod-auth-gssapi" which has a dependency on
"libgssapi-krb5-2". Is that essentially all I need?


My bad, I should provided you https://github.com/gssapi/mod_auth_gssapi


Fairly sure that's the source of the Debian package.


Is there an equivalent of "AuthBasicProvider ldap" that I would need
with gssapi to make it use the ldap provider?

>
As far as I understand https://httpd.apache.org/docs/2.4/mod/ 
mod_authnz_ldap.html#operation it not necessary because no Basic 
auth is performed. I would expect that REMOTE_USER is available to 
the module. I have tried, but documentation does not contradict.
What I meant was, "how do I tell GSSAPI that I wa

Re: remote address is localhost after upgrading tomcat instance behind reverse proxy from tomcat8.5 to tomcat9


Ivano,

On 11/7/24 05:38, Ivano Luberti wrote:

Hi Thomas,

Il 07-Nov-24 11:07, Mark Thomas ha scritto:

On 06/11/2024 21:17, Ivano Luberti wrote:
Hi, as stated in the subject, we had a correctly behaving tomcat 8.5 
behind a reverse proxy implemented with Apache.


After upgrading to Tomcat 9  every request is seen by tomcat as 
coming from localhost.


Apache and Tomcat are running on the same machine and reverse proxy 
is implemented forwarding the request to localhost.


To say it all, before the upgrade requests arrived to tomcat via ip 
v4 and after upgrade via ip v6


I have seen in the doc that there is a filter in tomcat to deal with 
this, but I would like to know why it was working with tomcat 8.5 and 
not with tomcat 9 and if there is a solution properly configuring 
Apache without touching Tomcat


If you upgraded Tomcat and are seeing changes in behaviour then 
doesn't that suggest Tomcat, rather than httpd, is where you need to 
make changes?


I was thinking more of an incomplete configuration in Apache , exposed 
by the upgrade (maybe I have bias with the people that had done that)


But after you suggestion I have looked into the old 
(working)server.xml)and discovered these few lines that I think explains 
it all


     

I will test them asap but I think this is definitely the reason.


If you are using HTTP(s) as your proxy protocol (instead of, for 
example, AJP), then this is 100% the issue you are experiencing.


It's important to configure the new Tomcat the same way the old Tomcat 
had been configured ;)


-chris


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

Re: Tomcat Service(s) on Windows, Procmon question


Jon,

On 11/7/24 14:53, Mcalexander, Jon J. wrote:

Sorry to top-reply, but does this regression exist in 10.1.31 as well, or only 
9.0.96?


It's all of the October releases :/

-chris


From: Christopher Schultz 
Sent: Thursday, November 7, 2024 1:16 PM
To: users@tomcat.apache.org
Subject: Re: Tomcat Service(s) on Windows, Procmon question

Jon, On 11/7/24 13: 08, Mcalexander, Jon J. wrote: > Happy Thursday everybody, > 
> I have a question around starting a Tomcat Service Instance on Windows servers. Is 
there a way to have the Tomcat Startup kick off a script before starting


Jon,



On 11/7/24 13:08, Mcalexander, Jon J. wrote:


Happy Thursday everybody,







I have a question around starting a Tomcat Service Instance on Windows servers. 
Is there a way to have the Tomcat Startup kick off a script before starting 
that will clear the contents of the workDir (Clear the cache so to say)?







We have run into some issues after upgrading our binaries to Tomcat 9.0.96 
where applications start throwing some unknown method errors when starting. The 
fix for this was to clear the workDir contents before startup and let Tomcat do 
it's recompile steps. Note, the app didn't change, but the binaries did.




Please note that there is a regression in 9.0.96 that you need to be

aware of that affects JSPs. It will affect you, since you are reporting

(a) missing method errors and (b) you want to clear your work directory,

presumably to remove .jsp -> .java -> .class files to trigger

recompilation of all of those.



I would pause and NOT deploy 9.0.96 because recompilation will stop the

app from throwing those missing-method errors, but some tags might

actually not behave properly.




We separate our CATALINA_HOME from our CATALINA_BASE, so app teams just need to 
restart their instance after the upgrade.







Doing this in Linux/Unix/MAC, is easier as we can do this with the setenv.sh 
script or in the startup or shutdown scripts. However Windows is more difficult 
as the instance runs as a service.







Any help here would be much appreciated.




As to your question about procrun running a script before it launches

Tomcat, I think the short answer is "no" but I do have an idea for you.



Create a new service called Tomcat-cleanup, make it a simply BAT/PS

script that cleans-out that directory, and make it a startup dependency

of the real Tomcat service.



-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: Tomcat Service(s) on Windows, Procmon question

Jon,

On 11/7/24 14:29, Mcalexander, Jon J. wrote:

From: Christopher Schultz 
Sent: Thursday, November 7, 2024 1:16 PM
To: users@tomcat.apache.org
Subject: Re: Tomcat Service(s) on Windows, Procmon question

Jon, On 11/7/24 13: 08, Mcalexander, Jon J. wrote: > Happy Thursday everybody, > 
> I have a question around starting a Tomcat Service Instance on Windows servers. Is 
there a way to have the Tomcat Startup kick off a script before starting

Jon,

On 11/7/24 13:08, Mcalexander, Jon J. wrote:

Happy Thursday everybody,

I have a question around starting a Tomcat Service Instance on Windows servers. 
Is there a way to have the Tomcat Startup kick off a script before starting 
that will clear the contents of the workDir (Clear the cache so to say)?

We have run into some issues after upgrading our binaries to Tomcat 9.0.96 
where applications start throwing some unknown method errors when starting. The 
fix for this was to clear the workDir contents before startup and let Tomcat do 
it's recompile steps. Note, the app didn't change, but the binaries did.

Please note that there is a regression in 9.0.96 that you need to be

aware of that affects JSPs. It will affect you, since you are reporting

(a) missing method errors and (b) you want to clear your work directory,

presumably to remove .jsp -> .java -> .class files to trigger

recompilation of all of those.

I would pause and NOT deploy 9.0.96 because recompilation will stop the

app from throwing those missing-method errors, but some tags might

actually not behave properly.

We separate our CATALINA_HOME from our CATALINA_BASE, so app teams just need to 
restart their instance after the upgrade.

Doing this in Linux/Unix/MAC, is easier as we can do this with the setenv.sh 
script or in the startup or shutdown scripts. However Windows is more difficult 
as the instance runs as a service.

Any help here would be much appreciated.

As to your question about procrun running a script before it launches

Tomcat, I think the short answer is "no" but I do have an idea for you.

Create a new service called Tomcat-cleanup, make it a simply BAT/PS

script that cleans-out that directory, and make it a startup dependency

of the real Tomcat service.

[Mcalexander, Jon J.]

Thanks for this information Chris. I can probably create this dependency, but 
then I wouldn’t want it to be running all the time, will having it as a 
dependency start said service? I could use Procrun to probably do this service, 
but then how do I tell it to run and then stop?

I honestly have no idea. I think if you have a script-as-a-service, it 
will run and then just finish.

-chris

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

Re: Tomcat Service(s) on Windows, Procmon question


Jon,

On 11/7/24 17:37, Mcalexander, Jon J. wrote:

Thank you. ☹


You could grab the just-rolled 9.0.97.

It's already got 2 +1 votes.

-chris


From: Christopher Schultz 
Sent: Thursday, November 7, 2024 4:16 PM
To: users@tomcat.apache.org
Subject: Re: Tomcat Service(s) on Windows, Procmon question

Jon, On 11/7/24 14: 53, Mcalexander, Jon J. wrote: > Sorry to top-reply, but does this 
regression exist in 10. 1. 31 as well, or only 9. 0. 96? It's all of the October releases 
:/ -chris > From: Christopher Schultz 


Jon,



On 11/7/24 14:53, Mcalexander, Jon J. wrote:


Sorry to top-reply, but does this regression exist in 10.1.31 as well, or only 
9.0.96?




It's all of the October releases :/



-chris




From: Christopher Schultz 
mailto:ch...@christopherschultz.net>>



Sent: Thursday, November 7, 2024 1:16 PM



To: users@tomcat.apache.org<mailto:users@tomcat.apache.org>



Subject: Re: Tomcat Service(s) on Windows, Procmon question







Jon, On 11/7/24 13: 08, Mcalexander, Jon J. wrote: > Happy Thursday everybody, > 
> I have a question around starting a Tomcat Service Instance on Windows servers. Is 
there a way to have the Tomcat Startup kick off a script before starting











Jon,















On 11/7/24 13:08, Mcalexander, Jon J. wrote:







Happy Thursday everybody,















I have a question around starting a Tomcat Service Instance on Windows servers. 
Is there a way to have the Tomcat Startup kick off a script before starting 
that will clear the contents of the workDir (Clear the cache so to say)?















We have run into some issues after upgrading our binaries to Tomcat 9.0.96 
where applications start throwing some unknown method errors when starting. The 
fix for this was to clear the workDir contents before startup and let Tomcat do 
it's recompile steps. Note, the app didn't change, but the binaries did.















Please note that there is a regression in 9.0.96 that you need to be







aware of that affects JSPs. It will affect you, since you are reporting







(a) missing method errors and (b) you want to clear your work directory,







presumably to remove .jsp -> .java -> .class files to trigger







recompilation of all of those.















I would pause and NOT deploy 9.0.96 because recompilation will stop the







app from throwing those missing-method errors, but some tags might







actually not behave properly.















We separate our CATALINA_HOME from our CATALINA_BASE, so app teams just need to 
restart their instance after the upgrade.















Doing this in Linux/Unix/MAC, is easier as we can do this with the setenv.sh 
script or in the startup or shutdown scripts. However Windows is more difficult 
as the instance runs as a service.















Any help here would be much appreciated.















As to your question about procrun running a script before it launches







Tomcat, I think the short answer is "no" but I do have an idea for you.















Create a new service called Tomcat-cleanup, make it a simply BAT/PS







script that cleans-out that directory, and make it a startup dependency







of the real Tomcat service.















-chris























-







To unsubscribe, e-mail: 
users-unsubscr...@tomcat.apache.org<mailto:users-unsubscr...@tomcat.apache.org<mailto:users-unsubscr...@tomcat.apache.org%3cmailto: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%3cmailto: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: Tomcat Service(s) on Windows, Procmon question


Jon,

On 11/7/24 13:08, Mcalexander, Jon J. wrote:

Happy Thursday everybody,

I have a question around starting a Tomcat Service Instance on Windows servers. 
Is there a way to have the Tomcat Startup kick off a script before starting 
that will clear the contents of the workDir (Clear the cache so to say)?

We have run into some issues after upgrading our binaries to Tomcat 9.0.96 
where applications start throwing some unknown method errors when starting. The 
fix for this was to clear the workDir contents before startup and let Tomcat do 
it's recompile steps. Note, the app didn't change, but the binaries did.


Please note that there is a regression in 9.0.96 that you need to be 
aware of that affects JSPs. It will affect you, since you are reporting 
(a) missing method errors and (b) you want to clear your work directory, 
presumably to remove .jsp -> .java -> .class files to trigger 
recompilation of all of those.


I would pause and NOT deploy 9.0.96 because recompilation will stop the 
app from throwing those missing-method errors, but some tags might 
actually not behave properly.



We separate our CATALINA_HOME from our CATALINA_BASE, so app teams just need to 
restart their instance after the upgrade.

Doing this in Linux/Unix/MAC, is easier as we can do this with the setenv.sh 
script or in the startup or shutdown scripts. However Windows is more difficult 
as the instance runs as a service.

Any help here would be much appreciated.


As to your question about procrun running a script before it launches 
Tomcat, I think the short answer is "no" but I do have an idea for you.


Create a new service called Tomcat-cleanup, make it a simply BAT/PS 
script that cleans-out that directory, and make it a startup dependency 
of the real Tomcat service.


-chris


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

Re: Tomcat Service(s) on Windows, Procmon question


Rob,

On 11/7/24 17:54, Rob Sargent wrote:


Thanks for this information Chris. I can probably create this 
dependency, but then I wouldn’t want it to be running all the time, 
will having it as a dependency start said service? I could use 
Procrun to probably do this service, but then how do I tell it to run 
and then stop?


I honestly have no idea. I think if you have a script-as-a-service, it 
will run and then just finish.


-chris



Does it matter much that the service is "running" but doing nothing 
after having cleaned up?


Again, I have no idea. I don't admin Windows, these are just educated 
guesses given my limited experience.


-chris


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

Re: Enable two way SSL in Apache Tomcat 10 Version 10.0.27

2023-08-09 Thread Christopher Schultz


Kaushal,

On 8/7/23 22:23, Kaushal Shriyan wrote:

Hi,

I have gone through https://tomcat.apache.org/tomcat-10.0-doc/ssl-howto.html.
Is there a way to enable two way SSL (mutual) in Apache Tomcat 10 Version
10.0.27?

Please guide me.

Thanks in Advance.


I see you have "gone through" the SSL Howto, but could you be specific 
about what you have actually done? For example, what does your 
 in server.xml look like, what does your web.xml look like, 
and what files do you have on the disk?


-chris

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

Re: Tomcat 10.1 -- Precedence of catalina.sh jvm Options vs server.xml options

2023-08-09 Thread Christopher Schultz


Chuck,

On 8/9/23 13:58, SCHWING, CHUCK wrote:

I've looked for the answer to this online and maybe I didn't read closely 
enough.
I'm running tomcat 10.1 with JDK17.0.6 and have defined a jvm startup option of 
"-Djdk.tls.client.protocols=TLSv1.2" in my copy of catalina.sh and the same TLS 
version is defined in my server.xml in my SSLHostConfig:
sslProtocol="TLS"
 protocols="TLSv1.2"

My question is:  What's the precedence in play?  Does catalina.sh override 
server.xml or is it the other way around?

We need to migrate to TLS1.3 and we're wondering how best to configure Tomcat 
10 so support TLS1.2 and TLS1.3 while we're migrating.


The system property you have shown above does not affect the behavior of 
Tomcat at all. This system property affects Java's built-in TLS *client* 
when making /outgoing/ connections.


If you specify "TLSv1.2" and no other protocols, then you will not 
enable TLSv1.3. You should specify:


  protocols="TLSv1.3, TLSv1.2"

in your  in order to enable TLSv1.3 and also accept 
TLSv1.2. Note that for TLSv1.3 there are other requirements, 
specifically a JVM with support if using JSSE or an OpenSSL 
implementation with support if using OpenSSL.


-chris

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

Re: Tomcat 8.5.64 maxHttpHeaderSize="6553600"

2023-08-14 Thread Christopher Schultz


Joel,

On 8/11/23 11:16, Joel Werginz wrote:

Version:  8.5.64

maxHttpHeaderSize=³6553600²


Are you able to try with 8.5.91? Your version is more than 2 years old 
and many fixes have been made to h2 stream handling in that time.


-chris


10-Aug-2023 16:36:21.530 FINE [https-openssl-apr-443-exec-7]
org.apache.coyote.http2.Http2UpgradeHandler.upgradeDispatch Entry,
Connection [1], SocketStatus [OPEN_READ]
10-Aug-2023 16:36:21.530 FINE [https-openssl-apr-443-exec-7]
org.apache.coyote.http2.Http2UpgradeHandler.init Connection [1], State
[CONNECTED]
10-Aug-2023 16:36:21.530 FINE [https-openssl-apr-443-exec-7]
org.apache.coyote.http2.Http2UpgradeHandler.upgradeDispatch Exit,
Connection [1], SocketState [UPGRADED]
10-Aug-2023 16:36:21.623 FINE [https-openssl-apr-443-exec-19]
org.apache.coyote.http2.Http2UpgradeHandler.upgradeDispatch Entry,
Connection [1], SocketStatus [OPEN_READ]
10-Aug-2023 16:36:21.623 FINE [https-openssl-apr-443-exec-19]
org.apache.coyote.http2.Http2UpgradeHandler.init Connection [1], State
[CONNECTED]
10-Aug-2023 16:36:21.623 FINE [https-openssl-apr-443-exec-19]
org.apache.coyote.http2.Http2Parser.validateFrame Connection [1], Stream
[23], Frame type [HEADERS], Flags [33], Payload size [16374]
10-Aug-2023 16:36:21.623 FINE [https-openssl-apr-443-exec-19]
org.apache.coyote.http2.StreamStateMachine.stateChange Connection [1],
Stream [23], State changed from [null] to [IDLE]
10-Aug-2023 16:36:21.623 FINE [https-openssl-apr-443-exec-19]
org.apache.coyote.http2.StreamStateMachine.stateChange Connection [1],
Stream [23], State changed from [IDLE] to [OPEN]
10-Aug-2023 16:36:21.623 FINE [https-openssl-apr-443-exec-19]
org.apache.coyote.http2.AbstractNonZeroStream.rePrioritise Connection [1],
Stream [23], Exclusive [true], Parent [0], Weight [220]
10-Aug-2023 16:36:21.623 FINE [https-openssl-apr-443-exec-19]
org.apache.coyote.http2.Http2Parser.readHeaderPayload Connection [1],
Stream [23], Processing headers payload of size [16,369]
10-Aug-2023 16:36:21.623 FINE [https-openssl-apr-443-exec-19]
org.apache.coyote.http2.Stream.emitHeader Connection [1], Stream [23],
HTTP header [:method], Value [GET]
10-Aug-2023 16:36:21.623 FINE [https-openssl-apr-443-exec-19]
org.apache.coyote.http2.Stream.emitHeader Connection [1], Stream [23],
HTTP header [:authority], Value [mdmsdev6.intranet.dow.com]
10-Aug-2023 16:36:21.623 FINE [https-openssl-apr-443-exec-19]
org.apache.coyote.http2.Stream.emitHeader Connection [1], Stream [23],
HTTP header [:scheme], Value [https]
10-Aug-2023 16:36:21.623 FINE [https-openssl-apr-443-exec-19]
org.apache.coyote.http2.Stream.emitHeader Connection [1], Stream [23],
HTTP header [:path], Value [/ebx-ui/rest/user/v1/current]
10-Aug-2023 16:36:21.623 FINE [https-openssl-apr-443-exec-19]
org.apache.coyote.http2.Stream.emitHeader Connection [1], Stream [23],
HTTP header [sec-ch-ua], Value ["Not/A)Brand";v="99", "Google
Chrome";v="115", "Chromium";v="115"]
10-Aug-2023 16:36:21.623 FINE [https-openssl-apr-443-exec-19]
org.apache.coyote.http2.Stream.emitHeader Connection [1], Stream [23],
HTTP header [accept], Value [application/json]
10-Aug-2023 16:36:21.623 FINE [https-openssl-apr-443-exec-19]
org.apache.coyote.http2.Http2UpgradeHandler.upgradeDispatch Connection
error
org.apache.coyote.http2.ConnectionException: Connection [1], Stream 
[23],
Total header size too big
at
org.apache.coyote.http2.Http2Parser.readHeaderPayload(Http2Parser.java:454)
at
org.apache.coyote.http2.Http2Parser.readHeadersFrame(Http2Parser.java:253)
at 
org.apache.coyote.http2.Http2Parser.readFrame(Http2Parser.java:97)
at 
org.apache.coyote.http2.Http2Parser.readFrame(Http2Parser.java:69)
at
org.apache.coyote.http2.Http2UpgradeHandler.upgradeDispatch(Http2UpgradeHan
dler.java:334)
at
org.apache.coyote.http11.upgrade.UpgradeProcessorInternal.dispatch(UpgradeP
rocessorInternal.java:60)
at
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.jav
a:59)
at
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtoc
ol.java:831)
at
org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpoint.ja
va:2075)
at
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java
:49)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecu
tor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExec
utor.java:628)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.j
ava:61)
at java.base/java.lang.Thread.run(Thread.java:834)
10-Aug-2023 16:36:21.623 FINE [https-openssl-apr-443-exec-19]
org.apache.coyote.http2.Stream.receiveReset Connection [1], Stream [23],
Reset received due to [8]
10-Aug-2023 16:36:21.623 FINE [https-openssl-apr-443-exec-19]
org.apache.coyote

Re: [External] Re: listening all local addresses by default is not security best practice

2023-08-14 Thread Christopher Schultz

On 8/6/23 13:25, Amit Pande wrote:

My apologies if I missed any conclusion here.

 From the description of address attribute on HTTP connector:

"For servers with more than one IP address, this attribute specifies which address 
will be used for listening on the specified port. By default, the connector will listen 
all local addresses. Unless the JVM is configured otherwise using system properties, the 
Java based connectors (NIO, NIO2) will listen on both IPv4 and IPv6 addresses when 
configured with either 0.0.0.0 or ::. The APR/native connector will only listen on IPv4 
addresses if configured with 0.0.0.0 and will listen on IPv6 addresses (and optionally 
IPv4 addresses depending on the setting of ipv6v6only) if configured with ::."

Is it possible to update the behavior to listen to loopback address only like 
was done for AJP connectors.

On my Tomcat 9.0.78 netstat output - I see Tomcat using 0.0.0.0 by default unless we 
define address as "127.0.0.1" :

tcp0  0 0.0.0.0:39054   0.0.0.0:*   LISTEN  
28539/java

Given the documentation quoted above, I would expect that Tomcat would 
bind to ::1 unless otherwise specified ("all LOCAL addresses", emphasis 
mine). The behavior you demonstrate above, and the code agree that 
Tomcat will listen on all PUBLIC interfaces, not local ones, by default.

I believe the documentation should be changed to reflect reality, 
because changing this default could break a lot of installations. 
Changing the default AJP binding to localhost made sense because a 
publicly-exposed AJP connector is very insecure, while having HTTP(S) 
exposed publicly should not present much risk at all.

Also, is it right that we will need to have two connectors for IPv4 and IPv6 with address 
"127.0.0.1" and "::1" respectively to enable binding only on loopback addresses?

If we configure two connectors (IPv4 and IPv6 loopback), if one isn't 
available, we see:

 org.apache.catalina.LifecycleException: Protocol handler 
initialization failed
 at 
org.apache.catalina.connector.Connector.initInternal(Connector.java:1011)
 at 
org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
 at 
org.apache.catalina.core.StandardService.initInternal(StandardService.java:549)
 at 
org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
 at 
org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:1040)
 at 
org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
 at org.apache.catalina.startup.Catalina.load(Catalina.java:724)
 at org.apache.catalina.startup.Catalina.load(Catalina.java:746)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:498)
 at 
org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:307)
 at 
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:477)
 Caused by: java.net.SocketException: Protocol family unavailable
 at sun.nio.ch.Net.bind0(Native Method)

which has caused confusion/concerns.

What would be a better way to bind on "all available loopback addresses?

That *would* be handy if ::1 would bind to "all local [IPv4 and IPv6, as 
appropriate] addresses" just like APR does. Can you please file a BZ 
ticket for that? I'm surprised it doesn't already work like that, 
honestly, because it seems completely obvious to me that's how it 
/should/ work.

-chris

-Original Message-
From: Christopher Schultz 
Sent: Monday, November 28, 2022 5:21 PM
To: users@tomcat.apache.org
Subject: [External] Re: listening all local addresses by default is not 
security best practice

To whom it may concern,

On 11/23/22 14:31, tommydu1...@outlook.com wrote:

Hi there,

Product:<https://nam12.safelinks.protection.outlook.com/?url=https%3A%
2F%2Fbz.apache.org%2Fbugzilla%2Fdescribecomponents.cgi&data=05%7C0
1%7CAmit.Pande%40veritas.com%7C13ea9fddeb604e4b7dca08dad1978243%7Cfc8e
13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638052745907718347%7CUnknown%7C
TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC
I6Mn0%3D%7C3000%7C%7C%7C&sdata=o%2FwWU7LgTdFLS3L5njjEruLLho9JnSw2O
LV0%2BO%2BnR5c%3D&reserved=0>

  >
  > [snip]

The default behaviour of http connector is listenning all interfaces.

False.

It is found in the description of "address" in attributes section.
(https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftom
cat.apache.org%2Ftomcat-9

Re: Forwarding request to a different servlet

2023-08-14 Thread Christopher Schultz


Andy,

On 8/13/23 04:24, Andy Pont wrote:

I wrote...


Progress of sorts!  The request is now returning 302 instead of 404!

Looking in the log files for the backend, it has a message that says 
“Robot requests must be rejected” and the 302 response is due to a 
redirect to a permission denied page.


My understanding was the .forward() method didn’t change anything on 
route in either direction.

>
Using JD-GUI I have looked at the class that is generates the above 
error message and it appears as the result of a check on the 
“user-agent” setting.  I am now puzzled as what is being received by the 
backend servlet is the same as if it is called directly without me 
intercepting it.


The .forward() should keep all request headers (and many other things) 
in-tact. You might want to log some things in plugins/whatever to see 
what is being done.


You should be using the *same objects* your servlet got for the request 
and response when calling RequestDispatcher.forward(). You can "wrap" 
them if necessary to make certain modifications.


The class I looked at contains a definition of a valid non-robot 
user-agent string.  Is it possible to modify the request to use this 
before forwarding it?


Yes, but I think you should not have to. What are the possible reasons 
for that specific 302 response? Are you *sure* it's complaining about 
the User-Agent string?


If not, am I better creating a new request for 
the backend and copy HTTP header and body content around as needed?


That will be a giant pain in the neck. Could this possibly be done with 
a redirect back through the client?


-chris

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

Re: Forwarding request to a different servlet

2023-08-15 Thread Christopher Schultz


Andy,

On 8/15/23 03:32, Andy Pont wrote:

Chris wrote…

The .forward() should keep all request headers (and many other things) 
in-tact. You might want to log some things in plugins/whatever to see 
what is being done.


You should be using the *same objects* your servlet got for the 
request and response when calling RequestDispatcher.forward(). You can 
"wrap" them if necessary to make certain modifications.
I have put the relevant parts of the source code onto PasteBin [1].  If 
anyone spots any stupid mistakes then please do let me know!


My code has some logging output in it but it doesn’t appear to be being 
added into the log files which are owned and created by the existing 
“backend”.  That is probably just down to me not having the correct 
logger context.


Yes, but I think you should not have to. What are the possible reasons 
for that specific 302 response? Are you *sure* it's complaining about 
the User-Agent string?
The log file from the backend records which Java class the mesage has 
come from so I am fairly confident I am looking in the correct class. 
There appear to be two functions that output the error in the log and 
which endup redirecting to permissionDenied.do [2].  I’m not sure which 
one is being called but the check and end result appear to be the same 
in both.


The UserAgent class that it references is complex (IMO) but as far as I 
can tell it is only looking at the “user-agent” header.


So it looks like the backend service IS being called, but rejecting the 
request because of the "UserAgent" object complaining about it.


I would log the User-Agent header from the request in your front-end 
before the RequestDispatcher.forward() call, and if possible, also log 
it in your backend service just before the "return false".


-chris

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

Re: tomcat timeouts on startup and on context deployment

2023-08-18 Thread Christopher Schultz


Ivano,

On 8/18/23 10:18, Ivano Luberti wrote:
Hello eveybody, in one of my use case, when upgrading a web application 
it coult happen that on startup the application has to perform some 
database operation that could require some time, even some minutes.


This happens typically when deploying the application via tomcat manager 
but could possibly happen when starting tomcat if the war file has been 
replaced while tomcat was down.


Where can I configure these timeouts?


What timeouts, specifically?

-chris

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

Re: tomcat timeouts on startup and on context deployment

2023-08-18 Thread Christopher Schultz


Ivano,

On 8/18/23 18:17, Ivano Luberti wrote:

It seems I had explained myself badly. I'll try again.

I need to know if there is and it is configurable a timeout on tomcat 
startup (in Eclipse you can configure it in the server configuration 
interface)


I need also to know if there is and it is configurable a timeout on 
application deployment when you use tomcat manager to deploy a war file 
or application start, fom tomcat manager interface as well


Tomcat doesn't wait for anything on startup except for the web 
applications to deploy. If your application takes long to start, Tomcat 
will take long to start. But Tomcat won't say "it's been 60 seconds, 
sorry, I'm killing the application" or anything like that.


If you use the Manager web application to deploy an application, it's 
possible that the tool you use for deployment (e.g. curl, or whatever 
makes the call to Tomcat's manager-deploy action) will have an HTTP 
timeout. Tomcat will complete the deployment work, but the 
deploying-client might not get a successful HTTP response within that 
time period.


But that's a timeout on the client end, not on Tomcat's end.

I'm just guessing at what timeout you are talking about, here. I may be 
totally off.


You said that Eclipse had a configurable timeout. What is that for / 
what is it called / what does it do?


-chris


Il 18/08/2023 22:57, Christopher Schultz ha scritto:

Ivano,

On 8/18/23 10:18, Ivano Luberti wrote:
Hello eveybody, in one of my use case, when upgrading a web 
application it coult happen that on startup the application has to 
perform some database operation that could require some time, even 
some minutes.


This happens typically when deploying the application via tomcat 
manager but could possibly happen when starting tomcat if the war 
file has been replaced while tomcat was down.


Where can I configure these timeouts?


What timeouts, specifically?

-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: Tomcat 9.0.x on Windows crashing

2023-08-24 Thread Christopher Schultz


Daniel,

On 8/23/23 13:03, Daniel Savard wrote:

I didn't specify the actual Tomcat version because the problem occurs under
all versions. We are running a commercial web application and all of sudden
after a while Tomcat is crashing without issuing any message. It is very
likely due to the application. But the vendor was of no help to solve this
problem which has existed for a long time. I suspect something like
insufficient memory allocated to the VM or something like that. Is there
anything I can do to gather more information on the root cause of this
issue?

Tomcat is running as a service and is restarted automatically if it
crashes. Again, the problem is very unlikely to be with Tomcat itself, but
the tuning of the VM.


What kind of environment (e.g. Windows vs UNIX, etc.)? What is running 
the service? Are there log files for the service which are different 
than usual (e.g. syslog vs catalina.out)?


What are your memory settings, and how much physical RAM do you have?

It's unlikely that the JVM is just disappearing without leaving any 
trace. If you are on Linux, maybe you are the victim of oome-killer? 
That will show in the syslog with a whole lot of output. Search syslog 
for "oom" and you will probably find it right away if that's the cause.


-chris

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

Re: [EXTERNAL] RE: DataSource Connection pool leak

2023-08-25 Thread Christopher Schultz


Tim,

On 8/25/23 10:48, Scott,Tim wrote:

Hi John,


Why does your app need 20 connections just to start up?  That's a
bit of a rhetorical question, but needing so many connections to
start up seems odd to me.

It doesn't. It only needs 1-2 at a time, but it makes 100s of queries
in loops, each time using a connection from the pool and passing it
back.


Yeah, this is what makes it a suspected leak, eh?


Are you using the Tomcat pool or another one?  If it's Tomcat, I
think you should use some of the abandoned connection settings
described here:

There're a few wrappers around the org.apache.commons.dbcp classes. I
have abandoned connection settings in place. The code - in fact, the
build - remains completely unchanged throughout my testing of 9.0.68,
9.0.70 - 9.0.79 as it used the same .war file. Whilst that doesn't
eliminate my code from the equation, it looks like a problem outside
my code. I will happily revise that view if nobody else has run into
a similar problem in the last 8 months - or if they have and found a
cause outside Tomcat.


I don't use 9.x but I haven't noticed a problem in 8.5.x and they are
very similar if not identical when it comes to the pooling code.


If your app is reserving connections and not releasing them, they
will be considered abandoned.  With logAbandoned=true, you'll get a
stack trace showing where the connection was obtained.

With 9.0.68 and 9.0.70 (indeed with most Tomcat versions I've used
since 8.0... ) we have worked hard to ensure that it does release
connections back to the pool appropriately. These connections are not
"abandoned" - a release was attempted.


Sometimes the "abandoned" configuration is not quite correct. Can you
post your  configuration for your application? Remove secrets
of course.

-chris

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

Re: OT: where does JSTL set thsi cookie? javax.servlet.jsp.jstl.fmt.request.charset

2023-08-25 Thread Christopher Schultz


Ivano,

On 8/25/23 10:50, Ivano Luberti wrote:
Hi, I understand that this question can be OT but I don't know where to 
search for.


Looking into tomcat manager sessions I see this cookie set in each session

     javax.servlet.jsp.jstl.fmt.request.charset     ISO-8859-1

The value ISO-8859-1 i set even though the file encoding of the java 
launch option is set to UTF-8


The JVM's charset probably doesn't matter at all. What matters is the 
charset that client is using for a particular request. I'm not sure why 
JSTL bothers to set a cookie for this value. It should be available in 
every request.


-chris

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

Re: Tomcat 9.0.x on Windows crashing

2023-08-30 Thread Christopher Schultz


Daniel,

On 8/28/23 14:37, Daniel Savard wrote:

Le jeu. 24 août 2023 à 13:06, Christopher Schultz <
ch...@christopherschultz.net> a écrit :


Daniel,

On 8/23/23 13:03, Daniel Savard wrote:

I didn't specify the actual Tomcat version because the problem occurs

under

all versions. We are running a commercial web application and all of

sudden

after a while Tomcat is crashing without issuing any message. It is very
likely due to the application. But the vendor was of no help to solve

this

problem which has existed for a long time. I suspect something like
insufficient memory allocated to the VM or something like that. Is there
anything I can do to gather more information on the root cause of this
issue?

Tomcat is running as a service and is restarted automatically if it
crashes. Again, the problem is very unlikely to be with Tomcat itself,

but

the tuning of the VM.


What kind of environment (e.g. Windows vs UNIX, etc.)? What is running
the service? Are there log files for the service which are different
than usual (e.g. syslog vs catalina.out)?

What are your memory settings, and how much physical RAM do you have?

It's unlikely that the JVM is just disappearing without leaving any
trace. If you are on Linux, maybe you are the victim of oome-killer?
That will show in the syslog with a whole lot of output. Search syslog
for "oom" and you will probably find it right away if that's the cause.

-chris



Hi Chris,

Thanks for the answer.  It is running on Windows and it is running as a
service which is configured to restart if it fails. No different log files
at my knowledge except application logs.

There is 14 GB physical RAM on this server. Initial memory pool is 4 GB and
maximum memory pool is 8 GB.

Well, the only thing I can say is Tomcat is failing at some point and
shutting itself down or being shutdown or killed, I cannot say the JVM
itself gets killed.


Windows... so Linux oome killer isn't a likely cause :)

"Windows Service" could mean a lot of things. Are you using the 
procrun-based service that Tomcat ships with? That should create 
stderr-* and stdout-* files in your logs directory which will be 
completely different than application logs.


Look at catalina.out, stderr/stdout and see if you see anything in there 
around the suspected time of termination.


-chris

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

Re: [EXTERNAL] RE: DataSource Connection pool leak

2023-08-30 Thread Christopher Schultz


Tim,

On 8/29/23 10:33, Scott,Tim wrote:

Hi all,

Thanks for your responses. I think I've found the problem.

My wrapping class which detects the invocation of the close() method to 
decrement its count is no longer decrementing its count because 
method.getDeclaringClass() has changed from java.sql.Connection to 
java.lang.AutoCloseable.

Is it safe to check for either java.sql.Connection or java.lang.AutoCloseable?

.. or should I just check for the "close()" method invocation, based on the 
fact that I'm not wrapping anything (here) that I shouldn't be counting?


That depends upon the point of the whole thing. What, um, is the point 
of the whole thing?


-chris

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

Re: Solved: DataSource Connection pool [non] leak

2023-08-31 Thread Christopher Schultz

Tim,

On 8/31/23 04:03, Scott,Tim wrote:

Hi Chris,

Hi all,

Thanks for your responses. I think I've found the problem.

My wrapping class which detects the invocation of the close() method to
decrement its count is no longer decrementing its count because
method.getDeclaringClass() has changed from java.sql.Connection to
java.lang.AutoCloseable.

Is it safe to check for either java.sql.Connection or java.lang.AutoCloseable?

.. or should I just check for the "close()" method invocation, based on the
fact that I'm not wrapping anything (here) that I shouldn't be counting?

That depends upon the point of the whole thing. What, um, is the point
of the whole thing?

The wrapping class is to limit the number of active connections, waiting up to a configured time
for one to become idle if necessary. I can't recall if this was because the timeout or the limit
was not configurable when this was first written in 2007. The count is decremented if the called
method is "close" and it's from the expected Class. Previously this was
java.sql.Connection, now it also accepts "close" from java.lang.AutoCloseable to
decrement the count.

What you describe above is the job of a connection pool, and Tomcat
provides two of them for your selection. There are a host of others
available for Java as well. I highly recommend that you use one of those
instead of trying to re-invent this particular wheel.

As the count wasn't being decremented, the active concurrent limit was quickly
(believed to be) reached.

I discussed this with a colleague who had previously worked with this
application. There was some consternation about the approach but it was agreed
that this was the least risk answer - for an application we're dropping support
for in December, it is not worth rewriting. This will at least enable
deployments to address vulnerabilities fixed in 9.0.71+.

Okay :)

-chris

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

Re: [External] Re: Supporting Proxy Protocol in Tomcat


Jon,

On 9/4/23 10:41, Jonathan S. Fisher wrote:

Mark thank you again for your leadership and setting expectations. I'm
going to commit to working on this with anyone else that wants to help with
the goal of a patch by year end. I want to nail the patch with minimal
rework that meets Tomcat project quality standards. To that end, I'll
attempt to summarize what you expect here and if you could comment and
correct my understanding that would be appreciated.

It sounds like you're satisfied with the ubiquity of the Proxy protocol and
that it has an RFC


+1


We'll target just implementing the latest version of the Proxy protocol
We'll implement a "TrustedProxies" feature similar to what the Remote IP
Valve does


+1 This is very important. If it makes sense to do some refactoring to 
allow these features to share code, please do that as a completely 
separate commit in your PR. It will make things much easier to read and 
follow.



We'll implement a, or modify the RemoteIp, valve to be able to set the
remote IP from Proxy protocol headers
We'll follow the RFC spec and reject any request that does a proper Proxy
protocol header
I'm particularly interested in the Proxy protocol over Unix Domain Sockets,
so expect to see a lot of the work focused on this, but accepting Proxy
Protocol over TCP looks to be quite important from the comments on this
email chain


TCP is a much more important use-case IMHO.


If I may ask two things:
Can you summarize your desired implementation? What point in the stack
should we target to implement this?
One thing I'm not familiar with on Tomcat is the testing expectations. If
you can point to a set of unit tests and a set of integration tests and say
"Do it like this"


There are tons of unit tests in the Tomcat source tree. IMHO it's much 
more important to have /existing/ unit-tests than waiting for a long 
time to have "the perfect tests case(s)". If you commit decent 
unit-tests and there are opportunities to make them more "Tomcat-like" 
or share more code with existing unit-tests, that work can come later.



Anything else on the original patch you liked/didn't like? (
https://bz.apache.org/bugzilla/show_bug.cgi?id=57830)


Others know much more about the "right" way to get started on this, so 
I'll leave it to them to reply. I wouldn't want to lead you down the 
wrong path.


-chris


On Tue, Aug 29, 2023 at 3:13 PM Mark Thomas  wrote:


On 28/08/2023 18:44, Amit Pande wrote:

Oh, sure. So, what would be the best way to get some conclusion on this

thread?

Provide a patch for review based on the feedback provided here and in
the BZ issue.


https://bz.apache.org/bugzilla/show_bug.cgi?id=57830 The state of the

ticket isn't updated for long. Perhaps add comments/ask the folks on user
list to vote?

That is more likely to irritate folks rather than encourage them to help
you progress your patch.

Mark




Thanks,
Amit

-Original Message-
From: Mark Thomas 
Sent: Monday, August 28, 2023 11:20 AM
To: Tomcat Users List 
Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat


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

click links or open attachments unless you recognize the sender and know
the content is safe. If you believe this is a phishing email, use the
Report to Cybersecurity icon in Outlook.




28 Aug 2023 17:11:20 Amit Pande :


Mark,

Just checking - Did this issue get discussed in any of the core
members' meeting?


There are no such meetings. Discussion happens on the mailing lists.

Mark




Thanks,
Amit

-Original Message-
From: Amit Pande
Sent: Monday, July 31, 2023 9:29 AM
To: Tomcat Users List 
Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat

Yes, understood.

Thank you for clarifying. Even I was referring to initial consensus
without any timeline or approach conclusion.

Thanks,
Amit

-Original Message-
From: Mark Thomas 
Sent: Friday, July 28, 2023 2:48 PM
To: users@tomcat.apache.org
Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat

On 28/07/2023 19:21, Amit Pande wrote:

Thank you all for the valuable discussion on this topic.

Is it okay to say that we're agreeing to adding proxy protocol
support in Tomcat?


I think that is a little too strong. At this point there is a proposed
approach and no one is objecting but until there is an actual patch to
discuss...

Keep in mind that any committer can veto a change.

My sense is that it should be possible to implement this feature while
addressing any concerns that may be raised but it is not guaranteed.

Mark




Thanks,
Amit

-Original Message-
From: Christopher Schultz 
Sent: Thursday, July 27, 2023 4:13 PM
To: users@tomcat.apache.org
Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat

All,

On 7/27/23 12:39, Mark Thomas wrote:

On 27/07/2023 16:27, Jonathan S. Fisher

Virtual Threads


All,

I have some questions about Virtual Threads and their use within Tomcat. 
Note that only Tomcat 11 currently has support for Virtual Threads when 
running on a version 19 or later JVM.


My (admittedly limited) understanding is that the use of Virtual 
Threads, specifically within Tomcat, will allow Tomcat to use fewer 
platform threads (e.g. native OS threads) to support a larger number of 
JVM/application threads for request-processing. The justification for 
this improvement is that request-processing threads spend a lot of time 
in an I/O-blocked state which, when using Virtual Threads, would no 
longer consume a platform thread.


There appears to only be one setting to enable Virtual Threads in Tomcat:



or



In both cases, there is only one setting to affect the number of 
"threads" (by any description) which the Executor will ultimately use 
(Connectors without an explicit Executor will create a non-shared 
Executor to be used internally). That setting is "maxThreads" which 
limits the total number of "threads" that the Executor will create.


The implementation of the VirtualThreadExecutor does not seem to have 
any upper-bound on the number of Virtual Threads that will be created at 
all. I believe this means that a large number of incoming requests (i.e. 
a burst) will result in the creation of a large number of Virtual 
Threads. Without an upper-bound, we are expecting that the JVM's 
(virtual) thread scheduler will schedule each application thread to be 
mounted to a platform thread in the order it was added to the queue 
(essentially in request-order).


Before Virtual Threads were introduced, the Executor would use a queue 
of requests to dispatch to available (non-Virtual) threads which would 
use that thread until the request was complete, then return the thread 
to the pool. With Virtual Threads, the same thing is essentially still 
happening except that (a) Tomcat no longer manages the thread pool (a 
JVM-defined one is being used instead) and (b) requests are immediately 
handed a (Virtual) thread to carry their execution.


I believe there are some subtle differences in how Tomcat will behave, 
now. As an example, if I have two applications running, say, the Tomcat 
Manager application and the Tomcat Examples application, without using 
Virtual Threads, each application's thread pools should be "fair" within 
the context of each application: requests are processed in the order 
they are received in Manager and Examples, separately. If all requests 
are equally "expensive" and everything is "fair", then requests to the 
Examples application are scheduled alongside those to the Manager 
application, and they can both execute simultaneously as well as 
separately-manage the order in which the requests are processed.


Once Virtual Threads are introduced, the requests are filed into a 
single JVM-wide thread-scheduling system where activity in one 
application can affect the other.


Let's replace Examples with RealWorldApp, an application that is 
expected to be used by users. Maybe a LOT of users. Without Virtual 
Threads, a high number of requests to RealWorldApp will not cause 
starvation of requests to (maybe the more important, at least for 
admins) the Manager. Once Virtual Threads are introduced, a limitless 
number of requests can be queued in front of a request to Manager, which 
can experience starvation.


While Tomcat did not previously implement any specific priority-queuing 
of requests, the use of separate Executors for each application 
effectively provided that kind of thing. Yes, each Executor can be 
configured separately to either use Virtual Threads or not, and so 
Manager can be configured to NOT use Virtual Threads while RealWorldApp 
can be configured to use Virtual Threads and the balance is "restored". 
But it is no longer possible to have RealWorldApp and RealWorldApp2 and 
Manager all with equally probable request-scheduling when using Virtual 
Threads. You can pick some subset of applications to get (essentially) 
priority by NOT using Virtual Threads, but the whole set of applications 
running in a single JVM will share a single Executor with FIFO behavior. 
If an application creates Virtual Threads (hey, why not?! they are 
cheaper!) then they will be scheduled alongside the request-processing 
threads as well.


Do I understand things correctly? Is my scenario of request-starvation 
for a little-used but potentially critical application (e.g. Manager) a 
real concern, or am I missing something fundamental about the way 
Virtual Threads are scheduled relative to other Virtual Threads, and 
relative to non-virtual threads?


-chris

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

Re: CIS Tomcat 8 Benchmark (v1.1.0) -- Questions


Mark, Robert, et al,

On 9/5/23 11:26, Mark Thomas wrote:
I spoke to some CIS representatives at a recent conference given that I 
have concerns about the quality of some of the recommendations.


It appears that these benchmarks are effectively crowdsourced. My 
primary concern is that there is no validation of the resulting 
recommendations so they run the risk of reinforcing current widespread 
bad practice as well as good practice.


This is interesting information. Lore really isn't a good source of 
security information. :( It makes me wonder why they are charging for 
that kind of information if it's basically the output of an internet 
search for "how do i secure a Tomcat installation".


Regarding the suggestion to edit the contents of a JAR, that is a bad 
idea on so many levels.


+1

Assuming that you are using signed JAR files, what you end up with is a 
JAR whose signature can no longer be validated. This would require that 
you disable JAR signing, which is probably another no-no when it comes 
to security -- and I'd agree -- if you have signed JARs you ought to be 
validating them. Another option would be to re-sign the modified JAR 
file with an internal certificate but that can present its own 
challenges. Most dev teams would just implement some kind of lazy 
auto-signing process with the cert and key sitting right on the server 
where it's being used, and at that point you are giving an attacker 
everything they need to work-around your security controls.


I'd argue that rather than spending time hiding the current Tomcat 
version - which is nothing more than security by obscurity - system 
admins should be investing time in an update process that allows easy 
updates (and roll-backs) to the Tomcat version. You only need to hide 
the version number if you aren't on top of your security updates. And if 
you aren't on top of your security updates you have bigger problems than 
needing to hide the version number.


+1

https://tomcat.apache.org/presentations.html#latest-split-installation

If you find you need to hide this version number to appease auditors - 
and using smarter auditors isn't an option - then there are a range of 
options as set out in the Tomcat 8.5 security guide. That guide also 
provides the correct way to override the version number (if you really 
need to) without editing the JAR contents. In short, you can simply 
override the individual file by placing at the right place in the file 
system:


$CATALINA_BASE/lib/org/apache/catalina/util/ServerInfo.properties


+1

The only argument /against/ doing that in the past that I've ever seen 
was that they "didn't want to pollute [their] Tomcat installation" which 
is crazy when the alternative is to alter a signed JAR provided by a 
trusted vendor.


This is also probably worth a read:
https://cwiki.apache.org/confluence/display/TOMCAT/Community+Review+of+DISA+STIG

I would bet that many of the items listed here have overlap with some of 
the more dubious items coming from CIS.


Hope that helps,
-chris



On 05/09/2023 14:54, Robert Turner wrote:
Thanks Peter. Just to be clear that I have no concern about the goal 
of the

test -- only the method for obtaining the information, and the "implied"
correction.

After going through the rest of the document I was provided, it seems to
"get more modern" as the questions go on -- suggesting the method of
improvement is additive, and possibly not corrective.


Improvements are definitely corrective as well as additive. Early 
versions of the guide had very odd advice regarding MIME type mapping 
that has since been removed.





On Tue, Sep 5, 2023 at 9:36 AM Peter Kreuser  wrote:


Robert,

While Mark Thomas will have a more detailled answer to this...

The finding behind this test is valid (information disclosure with 
server

version in responses), though the remediation listed here is from looong
time ago, when the was no ErrorReportValve to purge the version info.

So the CIS Tomcat 8(!) Guide is pretty outdated! Probably in more than
this spot...

Peter


Am 05.09.2023 um 14:03 schrieb Robert Turner :

While I think I know the answer to my question, I wanted to 
double-check

with the group to confirm.

I have been asked to perform the CIS Apache Tomcat 8 Benchmark (v1.1.0)

on

our production Tomcat installation, and I am looking through the

questions

/ information extraction requests, and I suspect they are not really
evaluating what they think they are, and furthermore encouraging bad
practices.

For instance, the first entry I have in the spreadsheet I was 
provided is

listed as follows:

CIS Control:
2.1 Alter the Advertised server.info String (Scored)

Description:
The server.info attribute contains the name of the application service.
This value is presented to Tomcat clients when clients connect to the
tomcat server.

Audit Procedures:
Perform the following to determine if the server.info value has been
changed:
Extract the ServerInfo.properties file and exami

Re: Virtual Threads


Mark,

On 9/5/23 15:55, Mark Thomas wrote:

On 05/09/2023 20:38, Christopher Schultz wrote:

All,

I have some questions about Virtual Threads and their use within 
Tomcat. Note that only Tomcat 11 currently has support for Virtual 
Threads when running on a version 19 or later JVM.


Not quite. All current versions support virtual threads when running on 
Java 21 or later.


Thanks for the correction. I just did a quick docs[1] search for 
"virtual" in Tomcat 10.x for example and I didn't see useVirtualThreads, 
so I assumed it wasn't in there. Maybe we need some documentation 
back-ports?


My (admittedly limited) understanding is that the use of Virtual 
Threads, specifically within Tomcat, will allow Tomcat to use fewer 
platform threads (e.g. native OS threads) to support a larger number 
of JVM/application threads for request-processing. The justification 
for this improvement is that request-processing threads spend a lot of 
time in an I/O-blocked state which, when using Virtual Threads, would 
no longer consume a platform thread.


There appears to only be one setting to enable Virtual Threads in Tomcat:



or



In both cases, there is only one setting to affect the number of 
"threads" (by any description) which the Executor will ultimately use 
(Connectors without an explicit Executor will create a non-shared 
Executor to be used internally). That setting is "maxThreads" which 
limits the total number of "threads" that the Executor will create.


The implementation of the VirtualThreadExecutor does not seem to have 
any upper-bound on the number of Virtual Threads that will be created 
at all. I believe this means that a large number of incoming requests 
(i.e. a burst) will result in the creation of a large number of 
Virtual Threads. Without an upper-bound, we are expecting that the 
JVM's (virtual) thread scheduler will schedule each application thread 
to be mounted to a platform thread in the order it was added to the 
queue (essentially in request-order).


The virtual thread scheduler uses a work stealing queue so it isn't 
quite FIFO.


That sounds like nit-picking to me. I suppose if each new Virtual Thread 
is assigned to a platform thread when it's initially queued, things can 
be executed in an not-strictly-FIFO-manner, but one has to assume work 
loads are equal (which they likely are not) and work is spread evenly 
across all the platform threads (which is likely) to have a general 
conversation about all this. I think the work-stealing ForkJoinPool is 
about as close to FIFO as you can get without introducing more expensive 
contention in order to enforce strict FIFO while not gaining much in the 
way of meaningful "fairness".


But it's probably worth mentioning that the queue might not be "strictly 
fair". What *is* fair, though -- and maybe more fair than in the past? 
-- is that pipelined requests have to get back in line instead of 
jumping the queue. I think the old blocking JIO connector would allow 
pipelined requests to skip the queue, but all NIO-based connectors are 
"more fair" than that.


Before Virtual Threads were introduced, the Executor would use a queue 
of requests to dispatch to available (non-Virtual) threads which would 
use that thread until the request was complete, then return the thread 
to the pool. With Virtual Threads, the same thing is essentially still 
happening except that (a) Tomcat no longer manages the thread pool (a 
JVM-defined one is being used instead) and (b) requests are 
immediately handed a (Virtual) thread to carry their execution.


I believe there are some subtle differences in how Tomcat will behave, 
now. As an example, if I have two applications running, say, the 
Tomcat Manager application and the Tomcat Examples application, 
without using Virtual Threads, each application's thread pools should 
be "fair" within the context of each application: requests are 
processed in the order they are received in Manager and Examples, 
separately. If all requests are equally "expensive" and everything is 
"fair", then requests to the Examples application are scheduled 
alongside those to the Manager application, and they can both execute 
simultaneously as well as separately-manage the order in which the 
requests are processed.


The above assumes each application has a separate thread pool (which 
implies a separate Connector).


Yes, I'm sorry, I completely skipped over the "fact" that a separate 
 would be used for such a "priority" application such as the 
Manager. My example was assuming that each application had the 
possibility to use a separate .


Once Virtual Threads are introduced, the requests are filed into a 
single JVM-wide thread-scheduling system where activity in one 
application can affect the other.


Correct.

Let's replace Examples with RealWor

Re: Virtual Thread Configuration In Tomcat 11


William,

On 8/24/23 09:50, William Crowell wrote:

I did some performance testing with virtual threads on Apache Tomcat
11.0.0-M10 and JDK 21 (21+35-2513).  I have a simple REST service
using Spring 6.0.11 that does an insert into MySQL 8.0.32.

I have 3 separate boxes all running Rocky Linux 9.2 on AWS
(t3a.xlarge which is 4 vCPUs and 16GiB RAM):

1) An application server running Tomcat 11.0.0-M10 with JDK 21

2) MySQL 8.0.32

3) JMeter 5.6.2

I know that JDK 21 is nowhere near GA, but I got some interesting
results.  I did 10 test runs with useVirtualThreads=“true”, and 10
test runs without virtual threads (the default).  Each run used 1000
threads in JMeter for about 3 minutes and 20 seconds for a ramp up
time of 3 seconds.

What I found was using platform threads performed at least twice as
fast as virtual threads.  Maybe I am interpreting the results wrong,
but this is what I found consistently across each test.

Again, I realize that performance is not the only goal of virtual
threads.  Just my observations.


This is "interesting", for some values of interesting.

I'd be interested in what the application was doing. Virtual Threads 
seem to be aimed at things like Web Application Containers where there 
is a lot of wasted time in a thread's execution waiting on I/O 
(blocking). If you ignore the application's workload (hah!), the 
application server is almost entirely occupied with (a) reading the 
request and (b) writing the response. There is almost no "computation 
time" and so Virtual Threads make a whole lot of sense.


Once inside the application, that may not be true.

From what little reading I have done on Virtual Threads, there are some 
poison pills in there depending upon application design. For example, if 
your thread blocks while inside a synchronized{} block, then your 
Virtual Thread is "pinned" and will NOT be un-mounted from the platform 
thread during the blocking operation. So all of that high-speed 
context-switching and magic that VT is supposed to provide goes 
completely out the window when you used to have 200 threads with maybe 8 
of them actually running at once but swapping-out preemptively, but now 
you have 200 virtual threads with 8 of them running at once, but of the 
8 running at once, several of them are stopped dead unable to make any 
progress.


At $work, we have plenty of read-through cache routines like this:

private Object somethingBigLock = new Object();
private SomethingBig big = null;
public Object getSomethingBigFromDatabase() {
synchronized(somethingBigLock) {
  if(null == big) {
  big = reallyGetSomethingBigFromDb(); // Non-trivial
  }

  return big;
}
}

Even if reallyGetSomethingBigFromDb() is mostly blocking on I/O -- e.g. 
waiting for the db to respond to a query -- it will consume one of your 
platform threads and lock it up, leaving fewer platform threads 
available to do the other work.


Without a critical analysis of your application and the libraries it 
uses, it's hard to tell if what you are observing is that "virtual 
threads are not as fast as regular threads" or "your application is an 
anti-pattern for Virtual Threads". My guess is that your application 
and/or the libraries you are using need to be re-written so they no 
longer use "classic" synchronization and instead use things like 
ReentrantLock for a similar purpose to play-nice with VT. Or you can 
wait for the (likely) inevitable improvement of the JVM which allows for 
threads holding monitors to be unmounted from platform threads. My guess 
is that is in the future for the JVM.


-chris

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

Re: Virtual Thread Configuration In Tomcat 11

2023-09-06 Thread Christopher Schultz


William,

On 9/5/23 17:41, William Crowell wrote:

Great post earlier today!  This is a super interesting topic to me.

You can find the performance testing results located here: 
http://ec2-18-188-185-212.us-east-2.compute.amazonaws.com:8080/web-report/

I did 10 runs with 1000 threads with a ramp up time of 3 seconds for a duration 
of 200 seconds.  Ignore the 11th run.  This is a really simple REST application 
with Spring.  It just makes an insert into a MySQL table.  When I get a moment 
I will put my code into GitHub, but again, there is not much to it.  You can 
find a very similar Spring Boot example with embedded Tomcat here:

https://medium.com/@anil.java.story/embracing-virtual-threads-in-spring-boot-4140d3b8a5a

But he uses JDK 20 with --enable-preview turned on.

The mistake I think I made was that the inserts are not really blocking because 
they happen so quickly.  Maybe because I did not put enough load in the test?  
I have no synchronized blocks in my code.  So, it appeared to me that the 
inserts were taking twice the amount of time with virtual threads.  I think 
that extra time is just overhead of pinning virtual threads to a platform 
thread and managing the ForkJoinPool.

What is going to happen is that people are going to “flip the 
switch”…useVirtualThreads=”true”.  They will find that performance will not be 
as good as using an operating system thread and abandon virtual threads because 
their code does not block.

So, I need to come up with an example where my code blocks and redo the perf 
test and prove this out.  I don’t know.


Try setting this system property before running your tests and see if it 
produces any output on the server while the load test is running:


-Djdk.tracePinnedThreads=full

-chris

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

Re: Virtual Threads

2023-09-06 Thread Christopher Schultz


Mark,

On 9/6/23 03:29, Mark Thomas wrote:

On 05/09/2023 22:02, Christopher Schultz wrote:

Mark,

On 9/5/23 15:55, Mark Thomas wrote:

On 05/09/2023 20:38, Christopher Schultz wrote:

All,

I have some questions about Virtual Threads and their use within 
Tomcat. Note that only Tomcat 11 currently has support for Virtual 
Threads when running on a version 19 or later JVM.


Not quite. All current versions support virtual threads when running 
on Java 21 or later.


Thanks for the correction. I just did a quick docs[1] search for 
"virtual" in Tomcat 10.x for example and I didn't see 
useVirtualThreads, so I assumed it wasn't in there. Maybe we need some 
documentation back-ports?


Odd. It is there as an attribute on the Connector. And in 9.0.x and 
8.5.x too.


https://tomcat.apache.org/tomcat-10.0-doc/config/executor.html

I don't find the word "virtual" anywhere on that page.

The virtual thread scheduler uses a work stealing queue so it isn't 
quite FIFO.


That sounds like nit-picking to me.


It is, but it is nit-picking for a reason. Violetta did some testing 
which showed switching to virtual threads showed a small (about 1%) 
throughput improvement it also showed a much broader spread of 
latencies. That increase in spread is due to the work-stealing queue. 
For those users watch latency carefully, the change was viewed as a 
significant drawback of switching to virtual threads.


That's a significant point, thanks for reiterating it.




I think you have summed things up pretty well. I don't see a way with 
the current API to specify multiple virtual thread schedulers (which 
is what I think you would need to address this).


Yeah, in all of the coverage I've seen online, there are no examples 
where Virtual Threads are used with an "executor" other than one that 
(a) accepts Runnable tasks and (b) just generates a Virtual Thread 
from that task which appears to be "bound" to the build-in default 
JVM-wide Virtual Thread executor.


It would be potentially interesting to see an API which would allow 
different Executors to be used with Virtual Threads, even though the 
whole point of the entire thing is to avoid the (application-level) 
complexity of a thread pool/executor/etc. I think it does make sense, 
however, to be able to prioritize your threads a little bit. I haven't 
read anything about Virtual Threads and their priorities, so I assume 
it's just not part of anything user-facing at this point.


I haven't seen anything that suggests that there will be any such API 
but to be fair, I haven't been following the Loom project that closely.


For those of you that are finding this topic interesting, I'll have a 
talk on this at the ASF conference, Community Over Code in Halifax.


https://communityovercode.org/schedule-list/#TH001

More broadly, there are usually a reasonable number of Tomcat committers 
present at ASF conferences so this is a great opportunity to speak face 
to face with the committers.


+1

-chris


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

Re: Virtual Threads

2023-09-07 Thread Christopher Schultz


Mark,

On 9/6/23 16:29, Mark Thomas wrote:

On 06/09/2023 21:24, Christopher Schultz wrote:

On 9/6/23 03:29, Mark Thomas wrote:

On 05/09/2023 22:02, Christopher Schultz wrote:




Thanks for the correction. I just did a quick docs[1] search for 
"virtual" in Tomcat 10.x for example and I didn't see 
useVirtualThreads, so I assumed it wasn't in there. Maybe we need 
some documentation back-ports?


Odd. It is there as an attribute on the Connector. And in 9.0.x and 
8.5.x too.


https://tomcat.apache.org/tomcat-10.0-doc/config/executor.html

I don't find the word "virtual" anywhere on that page.


It is a Connector attribute, not an Executor attribute. There isn't much 
point using an executor with virtual threads.


Okay then perche 
https://tomcat.apache.org/tomcat-11.0-doc/config/executor.html#Virtual_Thread_Implementation 
?


-chris

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

Re: Virtual Thread Configuration In Tomcat 11

2023-09-07 Thread Christopher Schultz


William,

On 9/7/23 08:04, William Crowell wrote:

When I set -Djdk.tracePinnedThreads=short, then I see this:

…
Thread[#41,ForkJoinPool-1-worker-4,5,CarrierThreads]
 com.mysql.cj.jdbc.ConnectionImpl.isValid(ConnectionImpl.java:2516) <== 
monitors:1
Thread[#39,ForkJoinPool-1-worker-2,5,CarrierThreads]
 com.mysql.cj.jdbc.ConnectionImpl.isValid(ConnectionImpl.java:2516) <== 
monitors:1
Thread[#41,ForkJoinPool-1-worker-4,5,CarrierThreads]
 com.mysql.cj.jdbc.ConnectionImpl.setAutoCommit(ConnectionImpl.java:2005) 
<== monitors:1
Thread[#43,ForkJoinPool-1-worker-5,5,CarrierThreads]
 
com.mysql.cj.jdbc.ClientPreparedStatement.executeInternal(ClientPreparedStatement.java:893)
 <== monitors:1
 
com.mysql.cj.jdbc.ClientPreparedStatement.executeUpdateInternal(ClientPreparedStatement.java:1061)
 <== monitors:1
 
com.mysql.cj.jdbc.ClientPreparedStatement.executeUpdateInternal(ClientPreparedStatement.java:1009)
 <== monitors:1
Thread[#43,ForkJoinPool-1-worker-5,5,CarrierThreads]
 com.mysql.cj.jdbc.ConnectionImpl.commit(ConnectionImpl.java:791) <== 
monitors:1
Thread[#43,ForkJoinPool-1-worker-5,5,CarrierThreads]
 com.mysql.cj.jdbc.ConnectionImpl.setAutoCommit(ConnectionImpl.java:2005) 
<== monitors:1
…

I started digging into the MySQL client code: 
https://github.com/mysql/mysql-connector-j/blob/8.0.33/src/main/user-impl/java/com/mysql/cj/jdbc/ConnectionImpl.java

This class is littered with synchronized blocks, so now this makes sense to me 
why virtual threads would take longer than a regular OS thread.


This is precisely the kind of thing I was expecting to see.

If your "application code" (which includes everything your application 
does, including calling into libraries) contains lots of "synchronized" 
blocks, then I think this is the situation you will often find yourself in.


I would expect that if you were to increase the size of the virtual 
thread pool things would start to get better, but in order to truly use 
virtual threads effectively, you have to track-down and eliminate many 
uses of synchronized blocks and methods in both your application and the 
libraries you use.


I wouldn't expect virtual threads to become a very widely-deployed 
performance-optimization technique in the immediate future. I expect 
that, eventually, lots of code will be re-written to be more 
virtual-thread-friendly.


-chris

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

Re: question about tomcat manager Server Status page

2023-09-08 Thread Christopher Schultz


Ivano,

On 9/8/23 11:17, Ivano Luberti wrote:

Hi, looking at Server Status and Complete Server Status Page

I can see the following line:

Max threads: 200 Current thread count: 11 Current threads busy: 1 Keep 
alive sockets count: 1


But looking at the thread list under the line I can count 24 lines.

So what is the number of thread currently instantiated by tomcat? 11 or 24?


This is a good question. When I check my localhost Manager running 
8.5.x, I see this:


Max threads: -1 Current thread count: 4 Current threads busy: 1 Keep 
alive sockets count: 1


The number of threads shown in the http-nio-host-port section shows 5 
threads, 4 in the R state and one in the S state.


When running jstack against my JVM, I can see that there are only 4 exec 
threads running.


So I think the claim that there are only 11 threads in your JVM is 
correct. I believe the 24 lines you are seeing are something buggy in 
the Manager's view. I'll see if I can play around with it a little bit 
to see what's happening.


-chris

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

Re: Enhancement request?

2023-09-08 Thread Christopher Schultz


Jon,

On 9/8/23 14:21, Mcalexander, Jon J. wrote:

In seeing the latest messages about the manager application, something that I and my team 
would LOVE to have is just a Status app that provides all the items status wise that the 
Manager app does, without any of the "Application Management" like restarting 
an app, etc. I know all the pieces are out there in Catalina.jar, but I don't have the 
developer knowledge to put it together in a separate servlet that just calls the items 
needed from Catalina.

Is this something that any of the guru's have thought about putting together? 
I'm thinking it would be best to just be a web service, no gui, that you can 
call and get the json or xml output with the data so it can be incorporated 
into a dashboard.


Are you looking for...

1. Something with more limited capabilities (for less-trusted admins, or 
to reduce the possibilities for hacking)


2. Something with fewer distractions

3. Something with a JSON/XML interface instead of HTML

4. Something which has fewer lines of code

?

Or some combination of the above, or something else?

-chris

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

Re: Enhancement request?

2023-09-11 Thread Christopher Schultz


Jon,

On 9/8/23 17:09, Mcalexander, Jon J. wrote:

It would be something that combines all 4 of your items below. I
would be looking for something that can just give health status of
Tomcat and the apps being hosted by that instance. This
wouldn't/shouldn't have any "Admin" rights to do anything other than
provide info. HTML is fine, but I think from an automation and
dashboard reporting standpoint the json/xml stream/soap
response/whatever would be best.
Does the existing non-GUI Manager interface not already provide what you 
are looking for? Or maybe JMX (possibly via the JMXProxyServlet)? Direct 
access to JMX /does/ mean that the connecting client has very high 
privileges, though.



Now, in my possibly short sited view of the world, if wishes were
fishes type of thing, to ME it would be awesome if this was
automagically available via startup without having to do anything
special in the server.xml to make that app available only to
localhost on such and such port. Know what I mean? An instant
statement of health localhost URL. 😊
I think the term "health[y]" might mean different things to different 
people. I think if you need something to be available that reports 
healthiness of your own service and application, you should probably 
build-to-suit.


-chris


-----Original Message-
From: Christopher Schultz 
Sent: Friday, September 8, 2023 3:46 PM
To: users@tomcat.apache.org
Subject: Re: Enhancement request?

Jon,

On 9/8/23 14:21, Mcalexander, Jon J. wrote:

In seeing the latest messages about the manager application, something

that I and my team would LOVE to have is just a Status app that provides all
the items status wise that the Manager app does, without any of the
"Application Management" like restarting an app, etc. I know all the pieces
are out there in Catalina.jar, but I don't have the developer knowledge to put
it together in a separate servlet that just calls the items needed from
Catalina.


Is this something that any of the guru's have thought about putting

together? I'm thinking it would be best to just be a web service, no gui, that
you can call and get the json or xml output with the data so it can be
incorporated into a dashboard.

Are you looking for...

1. Something with more limited capabilities (for less-trusted admins, or to
reduce the possibilities for hacking)

2. Something with fewer distractions

3. Something with a JSON/XML interface instead of HTML

4. Something which has fewer lines of code

?

Or some combination of the above, or something else?

-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: page extends not working???

2023-09-11 Thread Christopher Schultz


Aryeh,

On 9/9/23 19:36, Aryeh Friedman wrote:

On Sat, Sep 9, 2023 at 1:23 PM Mark Thomas  wrote:


On 09/09/2023 11:52, Aryeh Friedman wrote:

Every other jsp in my webapp (and other webapps on the same tomcat
instance [9.0.75]) works and I am using a the default container but as
curl/catalina.out show BasePage is *NEVER* being called (either the
_jspService() or the getX()):


How have you configured your JSP(s) to use this alternative base class?


sudo cat /usr/local/apache-tomcat-9.0/webapps/tlaitc-dashboard-1a1/index.jsp

<%@page extends="dashboard.web.pages.BasePage"%>
hi x is ${x}

Output shown in log (sorry for not including the JSP the first time)
but to make it easier to find the output is "hi x is " when it should
be "hi x is 123234"... as you notice there are zero errors/warning in
catalina but there is none of the println's also... so the only thing
I can surmise is BasePage is never being called <%@page
extends="dashboard.web.pages.BasePage"%> somehow failed but I have
verified that correct spelling several times and also verified any
syntextual errors [including the contents of the string literal] will
show up in catalina.out (i.e. wrong class name is logged as an error)


Your _jspService method in your base class will never be called, because 
it is overridden by the auto-generated class for your JSP, which does 
not call super._jspService.


I do not believe that this:

Hi X is ${x}

...will result in this.getX() being called from the JSP. References in 
EL ${...} expressions will be resolved against the PageContext (and 
other wider contexts), not against the JSP class currently executing.


If you want to call this.getX() then you will need to do this:

Hi X is <% getX() %>

I wouldn't bother messing-around with class hierarchies in JSP. It 
usually doesn't get you much but almost always requires you to bind 
yourself very closely with the specific implementation of the JSP engine.


It would be far better to use typical MVC-style development where a 
servlet (or similar) handles the real work of the request, possibly 
including writing a value of "x" to the request attributes. Then forward 
your request to your JSP to produce the response content. This will be 
much more straightforward and you will have fewer problems like this, 
where expected behavior is confused by all the magic that JSP provides.


-chris

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

Re: page extends not working???

2023-09-12 Thread Christopher Schultz


Aryeh,

On 9/11/23 10:05, Aryeh Friedman wrote:

On Mon, Sep 11, 2023 at 9:47 AM Christopher Schultz
 wrote:


Aryeh,

On 9/9/23 19:36, Aryeh Friedman wrote:

On Sat, Sep 9, 2023 at 1:23 PM Mark Thomas  wrote:


On 09/09/2023 11:52, Aryeh Friedman wrote:

Every other jsp in my webapp (and other webapps on the same tomcat
instance [9.0.75]) works and I am using a the default container but as
curl/catalina.out show BasePage is *NEVER* being called (either the
_jspService() or the getX()):


How have you configured your JSP(s) to use this alternative base class?


sudo cat /usr/local/apache-tomcat-9.0/webapps/tlaitc-dashboard-1a1/index.jsp

<%@page extends="dashboard.web.pages.BasePage"%>
hi x is ${x}

Output shown in log (sorry for not including the JSP the first time)
but to make it easier to find the output is "hi x is " when it should
be "hi x is 123234"... as you notice there are zero errors/warning in
catalina but there is none of the println's also... so the only thing
I can surmise is BasePage is never being called <%@page
extends="dashboard.web.pages.BasePage"%> somehow failed but I have
verified that correct spelling several times and also verified any
syntextual errors [including the contents of the string literal] will
show up in catalina.out (i.e. wrong class name is logged as an error)


Your _jspService method in your base class will never be called, because
it is overridden by the auto-generated class for your JSP, which does
not call super._jspService.

I do not believe that this:

Hi X is ${x}

...will result in this.getX() being called from the JSP. References in
EL ${...} expressions will be resolved against the PageContext (and
other wider contexts), not against the JSP class currently executing.

If you want to call this.getX() then you will need to do this:

Hi X is <% getX() %>

I wouldn't bother messing-around with class hierarchies in JSP. It
usually doesn't get you much but almost always requires you to bind
yourself very closely with the specific implementation of the JSP engine.

It would be far better to use typical MVC-style development where a
servlet (or similar) handles the real work of the request, possibly
including writing a value of "x" to the request attributes. Then forward
your request to your JSP to produce the response content. This will be
much more straightforward and you will have fewer problems like this,
where expected behavior is confused by all the magic that JSP provides.


Thanks but I have a very specific use case which the following working
example below should make more clear:


<%@page import="dashboard.web.page.Page"%>
<%
 // THIS WOULD NOT BE NEEDED if <%@page extends="..."%> worked
 //
 // for now we don't need to keep the page object just
 // the setAttributes in our ctx
 new Page(pageContext);
%>



 <%@include file="/widgets/scripts/scripts.jsp"%>


  



and the Page class:

package dashboard.web.page;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.jsp.PageContext;

import org.petitecloud.util.PetiteCloudNullException;

// making this extend the right subclass plus working page
extends="" would mean zero in-line Java
// Copyright (C) 2023 TLAITC and contributors
public class Page
{
 public Page(PageContext ctx)
 {
 _dbc_construction(ctx);

 this.ctx=ctx;

 HttpServletRequest req=(HttpServletRequest) ctx.getRequest();
 String[] parts=req.getRequestURI().split("/");
 int split=2;

 if(parts[0].equals("http:"))
 split+=2;

 name="";
 for(int i=split;i
<%@page extends="dashboard.web.page.Page"%>



 <%@include file="/widgets/scripts/scripts.jsp"%>


  



Side note I am currently adding user detection to the above page class
to that it can auto-enforce ACL's


I'm not sure I understand the point of the whole exercise. Nothing you 
have in the PageContext class constructor cannot be done from within the 
JSP itself, or -- better yet -- in an <%include> used by as many pages 
as you want. *OR* ... you could do it in a Filter and apply it to all 
requests, storing the information in the request attributes, which is 
much more standard than directly modifying the page context.


-chris

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

Re: page extends not working???

2023-09-12 Thread Christopher Schultz


Aryeh,

On 9/12/23 12:42, Aryeh Friedman wrote:

On Tue, Sep 12, 2023 at 11:42 AM Christopher Schultz
 wrote:


Aryeh,

On 9/11/23 10:05, Aryeh Friedman wrote:

On Mon, Sep 11, 2023 at 9:47 AM Christopher Schultz
 wrote:


Aryeh,

On 9/9/23 19:36, Aryeh Friedman wrote:

On Sat, Sep 9, 2023 at 1:23 PM Mark Thomas  wrote:


On 09/09/2023 11:52, Aryeh Friedman wrote:

Every other jsp in my webapp (and other webapps on the same tomcat
instance [9.0.75]) works and I am using a the default container but as
curl/catalina.out show BasePage is *NEVER* being called (either the
_jspService() or the getX()):


How have you configured your JSP(s) to use this alternative base class?


sudo cat /usr/local/apache-tomcat-9.0/webapps/tlaitc-dashboard-1a1/index.jsp

<%@page extends="dashboard.web.pages.BasePage"%>
hi x is ${x}

Output shown in log (sorry for not including the JSP the first time)
but to make it easier to find the output is "hi x is " when it should
be "hi x is 123234"... as you notice there are zero errors/warning in
catalina but there is none of the println's also... so the only thing
I can surmise is BasePage is never being called <%@page
extends="dashboard.web.pages.BasePage"%> somehow failed but I have
verified that correct spelling several times and also verified any
syntextual errors [including the contents of the string literal] will
show up in catalina.out (i.e. wrong class name is logged as an error)


Your _jspService method in your base class will never be called, because
it is overridden by the auto-generated class for your JSP, which does
not call super._jspService.

I do not believe that this:

Hi X is ${x}

...will result in this.getX() being called from the JSP. References in
EL ${...} expressions will be resolved against the PageContext (and
other wider contexts), not against the JSP class currently executing.

If you want to call this.getX() then you will need to do this:

Hi X is <% getX() %>

I wouldn't bother messing-around with class hierarchies in JSP. It
usually doesn't get you much but almost always requires you to bind
yourself very closely with the specific implementation of the JSP engine.

It would be far better to use typical MVC-style development where a
servlet (or similar) handles the real work of the request, possibly
including writing a value of "x" to the request attributes. Then forward
your request to your JSP to produce the response content. This will be
much more straightforward and you will have fewer problems like this,
where expected behavior is confused by all the magic that JSP provides.


Thanks but I have a very specific use case which the following working
example below should make more clear:


<%@page import="dashboard.web.page.Page"%>
<%
  // THIS WOULD NOT BE NEEDED if <%@page extends="..."%> worked
  //
  // for now we don't need to keep the page object just
  // the setAttributes in our ctx
  new Page(pageContext);
%>



  <%@include file="/widgets/scripts/scripts.jsp"%>


   



and the Page class:

package dashboard.web.page;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.jsp.PageContext;

import org.petitecloud.util.PetiteCloudNullException;

// making this extend the right subclass plus working page
extends="" would mean zero in-line Java
// Copyright (C) 2023 TLAITC and contributors
public class Page
{
  public Page(PageContext ctx)
  {
  _dbc_construction(ctx);

  this.ctx=ctx;

  HttpServletRequest req=(HttpServletRequest) ctx.getRequest();
  String[] parts=req.getRequestURI().split("/");
  int split=2;

  if(parts[0].equals("http:"))
  split+=2;

  name="";
  for(int i=split;i
<%@page extends="dashboard.web.page.Page"%>



  <%@include file="/widgets/scripts/scripts.jsp"%>


   



Side note I am currently adding user detection to the above page class
to that it can auto-enforce ACL's


I'm not sure I understand the point of the whole exercise. Nothing you
have in the PageContext class constructor cannot be done from within the
JSP itself, or -- better yet -- in an <%include> used by as many pages
as you want. *OR* ... you could do it in a Filter and apply it to all
requests, storing the information in the request attributes, which is
much more standard than directly modifying the page context.


The idea is to avoid any custom entries in web.xml (which filters
require)


This is not entirely true, and seems to be an arbitrary requirement. The 
application is configured via web.xml. Why disallow any configuration in 
web.xml?



and the entire point is this is a top level template and
future versions will provide a number of standard setAttri

Re: page extends not working???

2023-09-13 Thread Christopher Schultz


Aryeh,

On 9/12/23 17:50, Aryeh Friedman wrote:

On Tue, Sep 12, 2023 at 1:51 PM Christopher Schultz
 wrote:


Aryeh,

On 9/12/23 12:42, Aryeh Friedman wrote:

On Tue, Sep 12, 2023 at 11:42 AM Christopher Schultz
 wrote:


Aryeh,

On 9/11/23 10:05, Aryeh Friedman wrote:

On Mon, Sep 11, 2023 at 9:47 AM Christopher Schultz
 wrote:


Aryeh,

On 9/9/23 19:36, Aryeh Friedman wrote:

On Sat, Sep 9, 2023 at 1:23 PM Mark Thomas  wrote:


On 09/09/2023 11:52, Aryeh Friedman wrote:

Every other jsp in my webapp (and other webapps on the same tomcat
instance [9.0.75]) works and I am using a the default container but as
curl/catalina.out show BasePage is *NEVER* being called (either the
_jspService() or the getX()):


How have you configured your JSP(s) to use this alternative base class?


sudo cat /usr/local/apache-tomcat-9.0/webapps/tlaitc-dashboard-1a1/index.jsp

<%@page extends="dashboard.web.pages.BasePage"%>
hi x is ${x}

Output shown in log (sorry for not including the JSP the first time)
but to make it easier to find the output is "hi x is " when it should
be "hi x is 123234"... as you notice there are zero errors/warning in
catalina but there is none of the println's also... so the only thing
I can surmise is BasePage is never being called <%@page
extends="dashboard.web.pages.BasePage"%> somehow failed but I have
verified that correct spelling several times and also verified any
syntextual errors [including the contents of the string literal] will
show up in catalina.out (i.e. wrong class name is logged as an error)


Your _jspService method in your base class will never be called, because
it is overridden by the auto-generated class for your JSP, which does
not call super._jspService.

I do not believe that this:

Hi X is ${x}

...will result in this.getX() being called from the JSP. References in
EL ${...} expressions will be resolved against the PageContext (and
other wider contexts), not against the JSP class currently executing.

If you want to call this.getX() then you will need to do this:

Hi X is <% getX() %>

I wouldn't bother messing-around with class hierarchies in JSP. It
usually doesn't get you much but almost always requires you to bind
yourself very closely with the specific implementation of the JSP engine.

It would be far better to use typical MVC-style development where a
servlet (or similar) handles the real work of the request, possibly
including writing a value of "x" to the request attributes. Then forward
your request to your JSP to produce the response content. This will be
much more straightforward and you will have fewer problems like this,
where expected behavior is confused by all the magic that JSP provides.


Thanks but I have a very specific use case which the following working
example below should make more clear:


<%@page import="dashboard.web.page.Page"%>
<%
   // THIS WOULD NOT BE NEEDED if <%@page extends="..."%> worked
   //
   // for now we don't need to keep the page object just
   // the setAttributes in our ctx
   new Page(pageContext);
%>



   <%@include file="/widgets/scripts/scripts.jsp"%>






and the Page class:

package dashboard.web.page;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.jsp.PageContext;

import org.petitecloud.util.PetiteCloudNullException;

// making this extend the right subclass plus working page
extends="" would mean zero in-line Java
// Copyright (C) 2023 TLAITC and contributors
public class Page
{
   public Page(PageContext ctx)
   {
   _dbc_construction(ctx);

   this.ctx=ctx;

   HttpServletRequest req=(HttpServletRequest) ctx.getRequest();
   String[] parts=req.getRequestURI().split("/");
   int split=2;

   if(parts[0].equals("http:"))
   split+=2;

   name="";
   for(int i=split;i
<%@page extends="dashboard.web.page.Page"%>



   <%@include file="/widgets/scripts/scripts.jsp"%>






Side note I am currently adding user detection to the above page class
to that it can auto-enforce ACL's


I'm not sure I understand the point of the whole exercise. Nothing you
have in the PageContext class constructor cannot be done from within the
JSP itself, or -- better yet -- in an <%include> used by as many pages
as you want. *OR* ... you could do it in a Filter and apply it to all
requests, storing the information in the request attributes, which is
much more standard than directly modifying the page context.


The idea is to avoid any custom entries in web.xml (which filters
require)


This is not entirely true, and seems to be an arbitrary requirement. The
application is configured via web.xml. Why disallow any configuration

Re: AW: Solution to "Invalid keystore format" (cross-posted to Tomcat Users List at Apache, and Java 400 List at Midrange)

2023-09-13 Thread Christopher Schultz


Shawn and Mark,

On 9/13/23 09:30, Mark Thomas wrote:

On 13/09/2023 14:00, Shawn Heisey wrote:

On 9/12/23 01:06, Thomas Hoffmann (Speed4Trade GmbH) wrote:

I moved away from using the proprietary java keystore format.
I switched to using Base64 PEM format. This is usually also the 
format you get from the certificate issuer.
No need to convert it into Java format any more and you can also open 
it with any text editor.


I have never been able to get a Java program to accept a 
certificate/key in PEM format.  The closest I've been able to come is 
creating a PKCS12 file with openssl.  Annoying because all the other 
software I use accepts PEM with no problem, and as you have said, PEM 
is the format generally produced by a CA.


How did you get it to take a PEM cert?


Tomcat has supported this for a while. The bulk of th ecode can be found 
in:


https://github.com/apache/tomcat/blob/main/java/org/apache/tomcat/util/net/jsse/PEMFile.java


I also have code on GitHub that is very similar.

https://github.com/ChristopherSchultz/pem-utils

The hard part is the wide variety of "private key" formats that are out 
there in the wild. Reading a certificate in PEM format from Java is 
pretty much a one-liner. But reading a private key in one of the many 
possible formats, encodings, encryption strategies, etc. requires miles 
and miles of code.


-chris

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

Re: AW: Solution to "Invalid keystore format" (cross-posted to Tomcat Users List at Apache, and Java 400 List at Midrange)

2023-09-14 Thread Christopher Schultz


Brian,

On 9/13/23 23:25, Brian Wolfe wrote:

The PKCS12 is the industry standard keystore format. Your mac should be
creating it in that version. You should get familiar using the pkcs12. Its
not difficult to set it up. keytool and openssl support pkcs12 and have for
some time now. Its possible your older keystores are of the storetype JKS
or JCEKS, JKS used to be the default I think back in Java 6. Anything newer
should throw a warning telling you the industry standard is pkcs12. But you
can still open older formats by specifying the "--storetype" option. Your
getting that error because you probably didn't tell it what kind it is and
its default assumption is wrong.

Using a keystore is much better for managing your keys than using PEM
files.


Why?


It's best practice to have seperate stores for keys and for trust.


+1, and using files in PEM format do not preclude this.


by default java has the "cacerts" file for establishing trust.


True, but not terribly relevant.

-chris


On Wed, Sep 13, 2023 at 8:16 PM James H. H. Lampert
 wrote:


Java Keystores work. And I don't find them especially difficult to work
with (other than new formats not being backward-compatible with older
JVMs, and as one who has made a comfortable living banging out code for
IBM Midrange boxes for over a quarter century, I am quite familiar with
a much worse variation on that theme, namely, unless you explicitly set
the TGTRLS parameter (and have the appropriate previous version compiler
installed, and don't need to go back more than it will let you), your
programs will not even *restore* onto a prior release system.

And the one time I attempted to get anything other than a Java Keystore
to work in Tomcat, on an IBM Midrange box, I failed miserably.

Putting shell-script wrappers around two different versions of keytool
on my work Mac, so that "keytool" launches the Java 8 version, and
"keytool-default" launches the default version (in the unlikely event
that I'd ever need it) was a relatively simple exercise.

--
JHHL

-
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: HSTS on 401 / error pages

2023-09-14 Thread Christopher Schultz


Thomas,

Please start a new thread next time.

On 9/14/23 02:20, Thomas Hoffmann (Speed4Trade GmbH) wrote:

Hello everyone,

I would like to get your opinion about the HttpHeaderSecurityFilter in Tomcat.
I configured HSTS in Tomcat and it works well.
When I do a pen-test with burpsuite it complains that HSTS header is missing on 
401 responses.
I couldn’t find much information about whether HSTS makes sense for error pages.

It seems that Tomcat doesn’t send HSTS on 401 pages but burpsuite expects the 
header.
Are there any pros and cons about sending HSTS on 401 response?


You should always return an HSTS header.

How have you configured your HttpHeaderSecurityFilter? What is causing 
the 401 response? Which application is responding with that status?


-chris

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

Re: AW: HSTS on 401 / error pages

2023-09-15 Thread Christopher Schultz


Thomas,

On 9/14/23 10:03, Thomas Hoffmann (Speed4Trade GmbH) wrote:

Hello Chris,


-Ursprüngliche Nachricht-
Von: Christopher Schultz 
Gesendet: Donnerstag, 14. September 2023 15:26
An: users@tomcat.apache.org
Betreff: Re: HSTS on 401 / error pages

Thomas,

Please start a new thread next time.


Sorry, I thought removing all content and subject is sufficient. Maybe the 
message-id header is used internally(?)


Absolutely. That's what "reply" does on a mailing list...




On 9/14/23 02:20, Thomas Hoffmann (Speed4Trade GmbH) wrote:

Hello everyone,

I would like to get your opinion about the HttpHeaderSecurityFilter in

Tomcat.

I configured HSTS in Tomcat and it works well.
When I do a pen-test with burpsuite it complains that HSTS header is

missing on 401 responses.

I couldn’t find much information about whether HSTS makes sense for

error pages.


It seems that Tomcat doesn’t send HSTS on 401 pages but burpsuite

expects the header.

Are there any pros and cons about sending HSTS on 401 response?


You should always return an HSTS header.

How have you configured your HttpHeaderSecurityFilter? What is causing the
401 response? Which application is responding with that status?

-chris



Here are the requested details:

SecurityFilter is set in the web.xml of the application:

httpHeaderSecurity

org.apache.catalina.filters.HttpHeaderSecurityFilter
true

 hstsEnabled
 true

...

Further down in the web.xml is a constraint:

  
  xxx
  /*
  

  
  yyy
  

  
  CONFIDENTIAL
  
  


There is no frontend-server, tomcat is directly accessed from the browser.
It seems that burpsuite didn’t send authentication in the first place and this 
resulted in 401.

If I use curl https:///  I get similar result:
< HTTP/1.1 401
< WWW-Authenticate: Negotiate
< Content-Type: text/html;charset=utf-8
< Content-Language: de
< Content-Length: 439
< Date: Thu, 14 Sep 2023 13:58:10 GMT

When providing credentials to curl, the following headers are also included:
< Strict-Transport-Security: max-age=31536000;includeSubDomains
< X-Frame-Options: DENY
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block

I hope this information helps.


Authentication is checked before any filters run, because authentication 
is performed by a Valve, all of which run before any Filters run.


I'm not sure there is a way around this without

a. Using a fronting server of some kind
b. Getting a change of some kind made to Tomcat
c. Hacking this yourself

(b) is probably the best option, though I'm not sure what the best form 
of server-support for this would be.


Making HttpHeaderSecurity available in a Valve-packaging would do the 
trick, but maybe this makes sense to add at a more fundamental level to 
Tomcat. The problem is that HSTS is only one of many security-related 
headers and maybe it's potential lifetime isn't that long. My guess is 
that sometime in the near future, TLS will simply be required for all 
web traffic. If we bake that kind of thing into core-Tomcat, it becomes 
something we will need to un-bake in the future, and chefs can tell you 
that un-baking things rarely works out well.


-chris

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

Re: How to setup Apache web server for a Tomcat deployed Spring application

2023-09-15 Thread Christopher Schultz


Martin,

On 9/15/23 14:48, Martin Moore wrote:

I have a situation where I want to call an Tomcat deployed Spring
application remotely without adding the port number (8080), I had tried to
use 80 in Connector but wasn't able to connect to it when outside the LAN.


What's the motivation, here? It may allow for more flexible solutions. 
Are you trying to use non-8080, or are you trying to use non-secure, or 
both?



So I resorted to creating a proxy server using Apache2 Web Server (along
side the Tomcat application server).

Unfortunately when I call the app using name1.domain.com/app/login it times
out and fails.
Following are the configuration for Apache2 and Tomcat:
In server.xml (Tomcat V8)
 http://qadat.qfls.idealab.unical.it/>com"
proxyPort="80"
   />

httpd.conf (under conf/ in Apache2)
...
LoadModule proxy_module modules/mod_proxy.so
...
ServerName  name1.domain. com:80


ProxyPass /app/login http://localhost:8080/app/login

ProxyPassReverse /app/login http://localhost:8080/app/login




Looks good so far, except I would put trailing / symbols on here:

 ProxyPass /app/login/ http://localhost:8080/app/login/
 ProxyPassReverse /app/login/ http://localhost:8080/app/login/

Your email program seems to have put links into hostnames that makes 
this a little difficult to interpret.



To note that on the local machine tomcat returns the app through
http://localhost:8080/app/login 

How to make the app requests proxied so that name1.domain.
com/app/login works and calls the
localhost:8080/app/login to return the Tomcat Spring app

To note that DocumentRoot was added and then removed and that the app
resides in webapps/ROOT


If you are using the ROOT web app, then you should be proxying / and not 
/app/login/ (unless you really expect to proxy exactly one URL). Is the 
app called 'app' or 'qadat'?


If you want to refer to your application as /app/ then you should deploy 
it at webapps/app


What URL are you actually typing into the browser URL bar?

-chris

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

[ANN] Community Over Code Conference NA 2023 in Halifax, Canada, 7-10 Oct 2023

2023-09-20 Thread Christopher Schultz


All,

Please join us in Halifax in 2½ weeks for Community Over Code, the ASF 
Conference.


The Tomcat and httpd tracks are combined for this conference, being held 
on the second of the four-day conference featuring a wide variety of 
presentations and panel-led discussions about wide-ranging topics 
related to the ASF and the projects you care about.


And of source, the Hallway Track is always a great opportunity to meet 
other developers, users, and committers to chat about whatever is on 
your mind.


The full schedule can be found here: https://communityovercode.org/schedule/

-chris

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

Re: SSL Cert install help.

2023-09-22 Thread Christopher Schultz


Bill,

On 9/22/23 13:25, Bill wrote:

Hello All,
  I may have started my SSL Cert install & config at step 2 instead of
step 1... :-(


Most mistakes are recoverable :)


Basically I have created my key store, my p12 file and have my cert all in
a sub directory of the conf directory.


All of those things are usually in the same file. What files do you 
actually have, and what is in each of them, specifically? If you have a 
keystore of any kind (including p12 files), post the output of:


$  keytool -list -keystore [filename]


I have updated the server xml with my connectors per online directions.
Yet my SSL (https) cert/site doesn't work.


Can you please post your  configuration, replacing any secrets?

Also, what do you mean "doesn't work"? Tomcat does not start? 
Connections are refused? Browser doesn't like server's cert? Can't 
complete handshake?



The catalina logs do not provide a whole lot of help for me as a TC novice.
I did see this in the log:

(org.apache.catalina.core.AprLifecycleListener.lifecycleEvent The Apache
Tomcat Native library which allows using OpenSSL was not found on the
java.library.path: [/usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib])


This is a warning. If you don't intend to use tcnative, you can disable 
the AprLifecycleListener and it will no longer emit that message.



but I'm pretty sure I didn't install native, but the regular version of TC.


The "native" connector is just a Connector, not all of Tomcat. The 
"regular" version of Tomcat supports several types of connectors, the 
"native" one included.



So my question is, was I supposed to install or turn something on before
beginning the process of key store and p12 file and connector configuration?


No, if you have your keystore in order and refer to it properly in the 
config then that's all you should need.


-chris

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

Re: I forget: does Tomcat have any problems with not having a ROOT context?


James,

On 9/25/23 12:17, James H. H. Lampert wrote:
I probably asked the question before, but does Tomcat have any problems 
with not having a ROOT context?


I always run with a ROOT context just to be able to do things like 
provide custom responses with clients request 
/no-such-app/application.yml and stuff like that.


This may not be true any more, but I have this comment in my ROOT 
web.xml that get auto-built/deployed by my build process:


  Dummy ROOT context to prevent 400 Bad Request 
responses


So it's possible that requesting /no-such-app/whatever will return 404 
these days, but at one point it returned 400 and I didn't like that.


-chris

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

Re: SSLHostConfig question


Jon,

On 9/26/23 11:32, Mcalexander, Jon J. wrote:
I have a question around the SSLHostConfig SSL Connector in Tomcat. 
In the   section, if the SSL Certificate is in a

Windows PFS Keystore, is it appropriate to add

certificateKeystoreType="PFX"

or

certificateKeystore="path to pfx file" type="PFX"

I'm finding reference to certificateKeystoreType, but not in regards to 
PKCS12/PFX types.


I don't think Tomcat supports "PFX" files per-se, but the intertubes say 
that PFX is PKCS12, which IS supported. So try using "PKCS12" which I 
think is the default.


-chris

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

Re: SSLHostConfig question


Mark,

On 9/26/23 12:54, Mark Thomas wrote:

On 26/09/2023 16:50, Christopher Schultz wrote:

Jon,

On 9/26/23 11:32, Mcalexander, Jon J. wrote:
I have a question around the SSLHostConfig SSL Connector in Tomcat. 
In the   section, if the SSL Certificate is in a

Windows PFS Keystore, is it appropriate to add

certificateKeystoreType="PFX"

or

certificateKeystore="path to pfx file" type="PFX"

I'm finding reference to certificateKeystoreType, but not in regards 
to PKCS12/PFX types.


I don't think Tomcat supports "PFX" files per-se, but the intertubes 
say that PFX is PKCS12, which IS supported. So try using "PKCS12" 
which I think is the default.


Default for all keystore types is JKS.

As Chris says, "pkcs12" should work.


Most recent JVMs will open a JKS file or PKCS12 file regardless of which 
type you actually specify. That was their solution to switching the 
default from JKS to PKCS12.


At this point, Tomcat should probably issue a warning if the type is 
"JKS" and just tell users "stop using JKS, use PKCS12 instead".


-chris

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

Re: SSLHostConfig question


Jonm

On 9/26/23 15:07, Mcalexander, Jon J. wrote:

Thank you, but which format of the line is correct?

certificateKeystoreType="pkcs12"

or

certificateKeystore="path to pfx file" type="pkcs12"


https://tomcat.apache.org/tomcat-9.0-doc/config/http.html#SSL_Support_-_Certificate

Here are the relevant attributes:

certificateKeystoreFile : path to your file
certificateKeystoreType : type of keystore file
type : type of /key/ (choose RSA, EC, or DSA - but don't choose DSA)

-chris


-Original Message-
From: Mark Thomas 
Sent: Tuesday, September 26, 2023 11:54 AM
To: users@tomcat.apache.org
Subject: Re: SSLHostConfig question

On 26/09/2023 16:50, Christopher Schultz wrote:

Jon,

On 9/26/23 11:32, Mcalexander, Jon J. wrote:

I have a question around the SSLHostConfig SSL Connector in Tomcat.
In the   section, if the SSL Certificate is in a
Windows PFS Keystore, is it appropriate to add

certificateKeystoreType="PFX"

or

certificateKeystore="path to pfx file" type="PFX"

I'm finding reference to certificateKeystoreType, but not in regards
to PKCS12/PFX types.


I don't think Tomcat supports "PFX" files per-se, but the intertubes
say that PFX is PKCS12, which IS supported. So try using "PKCS12"
which I think is the default.


Default for all keystore types is JKS.

As Chris says, "pkcs12" should work.

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

Tomcat 10 on RHEL 8 with Java 17

Hi All,

I just deployed Tomcat v10.1.13  on a new machine.  When I start Tomcat it says 
it has started but I don’t see the daemon running and I don’t have any logs.  I 
tried running Catalina.sh directly.

# ./catalina.sh start
Using CATALINA_BASE:   /usr/local/tomcat
Using CATALINA_HOME:   /usr/local/tomcat
Using CATALINA_TMPDIR: /usr/local/tomcat/temp
Using JRE_HOME:/usr/lib/jvm/java-17-openjdk-17.0.8.0.7-2.el8.x86_64
Using CLASSPATH:   
/usr/local/tomcat/bin/*:/usr/local/tomcat/bin/bootstrap.jar:/usr/local/tomcat/bin/tomcat-juli.jar
Using CATALINA_OPTS:   -XX:+UseG1GC -Xmx3000m
Tomcat started.

Not running – No Daemon + No Logs

# ./catalina.sh debug
Using CATALINA_BASE:   /usr/local/tomcat
Using CATALINA_HOME:   /usr/local/tomcat
Using CATALINA_TMPDIR: /usr/local/tomcat/temp
Using JAVA_HOME:   /usr/lib/jvm/java-17-openjdk-17.0.8.0.7-2.el8.x86_64
Using CLASSPATH:   
/usr/local/tomcat/bin/*:/usr/local/tomcat/bin/bootstrap.jar:/usr/local/tomcat/bin/tomcat-juli.jar
Using CATALINA_OPTS:   -XX:+UseG1GC -Xmx3000m
invalid option: --add-opens=java.base/java.lang=ALL-UNNAMED

Usage: jdb   

where options include:

There are several of the --add-opens statements that cause startup to fail in 
catalina.sh

# Add the module start-up parameters required by Tomcat
JAVA_OPTS="$JAVA_OPTS --add-opens=java.base/java.lang=ALL-UNNAMED"
JAVA_OPTS="$JAVA_OPTS --add-opens=java.base/java.io=ALL-UNNAMED"
JAVA_OPTS="$JAVA_OPTS --add-opens=java.base/java.util=ALL-UNNAMED"
JAVA_OPTS="$JAVA_OPTS --add-opens=java.base/java.util.concurrent=ALL-UNNAMED"
JAVA_OPTS="$JAVA_OPTS --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED"


Not sure what to do.

-Chris

Re: Tomcat 10 on RHEL 8 with Java 17

2023-09-27 Thread Christopher Schultz


Chris,

On 9/27/23 10:30, Christopher Bland wrote:

Hi All,

I just deployed Tomcat v10.1.13  on a new machine.  When I start Tomcat it says 
it has started but I don’t see the daemon running and I don’t have any logs.  I 
tried running Catalina.sh directly.

# ./catalina.sh start
Using CATALINA_BASE:   /usr/local/tomcat
Using CATALINA_HOME:   /usr/local/tomcat
Using CATALINA_TMPDIR: /usr/local/tomcat/temp
Using JRE_HOME:/usr/lib/jvm/java-17-openjdk-17.0.8.0.7-2.el8.x86_64
Using CLASSPATH:   
/usr/local/tomcat/bin/*:/usr/local/tomcat/bin/bootstrap.jar:/usr/local/tomcat/bin/tomcat-juli.jar
Using CATALINA_OPTS:   -XX:+UseG1GC -Xmx3000m
Tomcat started.

Not running – No Daemon + No Logs

# ./catalina.sh debug
Using CATALINA_BASE:   /usr/local/tomcat
Using CATALINA_HOME:   /usr/local/tomcat
Using CATALINA_TMPDIR: /usr/local/tomcat/temp
Using JAVA_HOME:   /usr/lib/jvm/java-17-openjdk-17.0.8.0.7-2.el8.x86_64
Using CLASSPATH:   
/usr/local/tomcat/bin/*:/usr/local/tomcat/bin/bootstrap.jar:/usr/local/tomcat/bin/tomcat-juli.jar
Using CATALINA_OPTS:   -XX:+UseG1GC -Xmx3000m
invalid option: --add-opens=java.base/java.lang=ALL-UNNAMED

Usage: jdb   

where options include:

There are several of the --add-opens statements that cause startup to fail in 
catalina.sh

# Add the module start-up parameters required by Tomcat
JAVA_OPTS="$JAVA_OPTS --add-opens=java.base/java.lang=ALL-UNNAMED"
JAVA_OPTS="$JAVA_OPTS --add-opens=java.base/java.io=ALL-UNNAMED"
JAVA_OPTS="$JAVA_OPTS --add-opens=java.base/java.util=ALL-UNNAMED"
JAVA_OPTS="$JAVA_OPTS --add-opens=java.base/java.util.concurrent=ALL-UNNAMED"
JAVA_OPTS="$JAVA_OPTS --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED"


Not sure what to do.


Try:

$ ./catalina.sh run

and post the output if it's not obvious what's happening.

-chris

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

Re: [External]Re: Tomcat 10 on RHEL 8 with Java 17

Hi Chris,

I didn’t get the error message.  Tomcat still isn’t starting

# ./catalina.sh run
Using CATALINA_BASE:   /usr/local/tomcat
Using CATALINA_HOME:   /usr/local/tomcat
Using CATALINA_TMPDIR: /usr/local/tomcat/temp
Using JRE_HOME:/usr/lib/jvm/java-17-openjdk-17.0.8.0.7-2.el8.x86_64
Using CLASSPATH:   
/usr/local/tomcat/bin/*:/usr/local/tomcat/bin/bootstrap.jar:/usr/local/tomcat/bin/tomcat-juli.jar
Using CATALINA_OPTS:   -XX:+UseG1GC -Xmx3000m

# ps -ef | grep tomc
root  104975  104815  0 13:08 pts/000:00:00 grep --color=auto tomc

@Darryl

Hi Darryl,

Just checked, permissions look correct

# ls -ld /var/log/tomcat/ /usr/local/tomcat/logs/
drwxr-x---. 2 tomcat tomcat 26 Sep 26 20:14 /usr/local/tomcat/logs/
drwxr-xr-x. 2 tomcat tomcat  6 Sep 26 19:48 /var/log/tomcat/


-Chris


From: Darryl Baker 
Date: Wednesday, September 27, 2023 at 12:59 PM
To: Tomcat Users List 
Subject: [External]Re: Tomcat 10 on RHEL 8 with Java 17
[You don't often get email from darryl.ba...@northwestern.edu. Learn why this 
is important at https://aka.ms/LearnAboutSenderIdentification ]

Chris,
With no logs at all check the permissions on the log directories and 
make sure that the user Tomcat is running as has write permissions there.  This 
sounds very much like what I ran into my first time setting up Tomcat from 
scratch.

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 <mailto:darryl.ba...@northwestern.edu>
(847) 467-6674 




On 9/27/23, 9:31 AM, "Christopher Bland" mailto:ch...@fdu.edu>> wrote:


Hi All,


I just deployed Tomcat v10.1.13 on a new machine. When I start Tomcat it says 
it has started but I don’t see the daemon running and I don’t have any logs. I 
tried running Catalina.sh directly.


# ./catalina.sh start
Using CATALINA_BASE: /usr/local/tomcat
Using CATALINA_HOME: /usr/local/tomcat
Using CATALINA_TMPDIR: /usr/local/tomcat/temp
Using JRE_HOME: /usr/lib/jvm/java-17-openjdk-17.0.8.0.7-2.el8.x86_64
Using CLASSPATH: 
/usr/local/tomcat/bin/*:/usr/local/tomcat/bin/bootstrap.jar:/usr/local/tomcat/bin/tomcat-juli.jar
Using CATALINA_OPTS: -XX:+UseG1GC -Xmx3000m
Tomcat started.


Not running – No Daemon + No Logs


# ./catalina.sh debug
Using CATALINA_BASE: /usr/local/tomcat
Using CATALINA_HOME: /usr/local/tomcat
Using CATALINA_TMPDIR: /usr/local/tomcat/temp
Using JAVA_HOME: /usr/lib/jvm/java-17-openjdk-17.0.8.0.7-2.el8.x86_64
Using CLASSPATH: 
/usr/local/tomcat/bin/*:/usr/local/tomcat/bin/bootstrap.jar:/usr/local/tomcat/bin/tomcat-juli.jar
Using CATALINA_OPTS: -XX:+UseG1GC -Xmx3000m
invalid option: --add-opens=java.base/java.lang=ALL-UNNAMED


Usage: jdb   


where options include:


There are several of the --add-opens statements that cause startup to fail in 
catalina.sh


# Add the module start-up parameters required by Tomcat
JAVA_OPTS="$JAVA_OPTS --add-opens=java.base/java.lang=ALL-UNNAMED"
JAVA_OPTS="$JAVA_OPTS --add-opens=java.base/java.io=ALL-UNNAMED"
JAVA_OPTS="$JAVA_OPTS --add-opens=java.base/java.util=ALL-UNNAMED"
JAVA_OPTS="$JAVA_OPTS --add-opens=java.base/java.util.concurrent=ALL-UNNAMED"
JAVA_OPTS="$JAVA_OPTS --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED"




Not sure what to do.


-Chris




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

Re: [External]Re: Tomcat 10 on RHEL 8 with Java 17

Hi Thomas,

I didn’t post those checks.  I ran

ps -ef | egrep -I ‘tomc|java’

as well as

netstat -tlpn

I did not see any indication that Tomcat had started.

@Stephanie

Hi Stephanie,

I checked the ownership and permissions plus ran chown -R tomcat:tomcat 
/usr/local/tomcat

-Chris

From: Thomas Hoffmann (Speed4Trade GmbH) 

Date: Wednesday, September 27, 2023 at 2:25 PM
To: Tomcat Users List 
Subject: AW: [External]Re: Tomcat 10 on RHEL 8 with Java 17
Hi Chris,

> -Ursprüngliche Nachricht-
> Von: Christopher Bland 
> Gesendet: Mittwoch, 27. September 2023 19:19
> An: Tomcat Users List 
> Betreff: Re: [External]Re: Tomcat 10 on RHEL 8 with Java 17
>
> Hi Chris,
>
> I didn’t get the error message.  Tomcat still isn’t starting
>
> # ./catalina.sh run
> Using CATALINA_BASE:   /usr/local/tomcat
> Using CATALINA_HOME:   /usr/local/tomcat
> Using CATALINA_TMPDIR: /usr/local/tomcat/temp
> Using JRE_HOME:/usr/lib/jvm/java-17-openjdk-17.0.8.0.7-2.el8.x86_64
> Using CLASSPATH:
> /usr/local/tomcat/bin/*:/usr/local/tomcat/bin/bootstrap.jar:/usr/local/tomc
> at/bin/tomcat-juli.jar
> Using CATALINA_OPTS:   -XX:+UseG1GC -Xmx3000m
>
> # ps -ef | grep tomc
> root  104975  104815  0 13:08 pts/000:00:00 grep --color=auto tomc

You grep for tomcat. The file starts a java-process. Maybe it doesn’t catch the 
right process.
Could you check whether java processes are running?

Or check "netstat -tulpen" if something is listening on the specified port 
(according to server.xml).


> @Darryl
>
> Hi Darryl,
>
> Just checked, permissions look correct
>
> # ls -ld /var/log/tomcat/ /usr/local/tomcat/logs/ drwxr-x---. 2 tomcat tomcat
> 26 Sep 26 20:14 /usr/local/tomcat/logs/ drwxr-xr-x. 2 tomcat tomcat  6 Sep 26
> 19:48 /var/log/tomcat/
>
>
> -Chris
>
>
> From: Darryl Baker 
> Date: Wednesday, September 27, 2023 at 12:59 PM
> To: Tomcat Users List 
> Subject: [External]Re: Tomcat 10 on RHEL 8 with Java 17 [You don't often get
> email from darryl.ba...@northwestern.edu. Learn why this is important at
> https://aka.ms/LearnAboutSenderIdentification ]
>
> Chris,
> With no logs at all check the permissions on the log directories and 
> make
> sure that the user Tomcat is running as has write permissions there.  This
> sounds very much like what I ran into my first time setting up Tomcat from
> scratch.
>
> 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 <mailto:darryl.ba...@northwestern.edu>
> (847) 467-6674 
>
>
>
>
> On 9/27/23, 9:31 AM, "Christopher Bland"  <mailto:ch...@fdu.edu>> wrote:
>
>
> Hi All,
>
>
> I just deployed Tomcat v10.1.13 on a new machine. When I start Tomcat it
> says it has started but I don’t see the daemon running and I don’t have any
> logs. I tried running Catalina.sh directly.
>
>
> # ./catalina.sh start
> Using CATALINA_BASE: /usr/local/tomcat
> Using CATALINA_HOME: /usr/local/tomcat
> Using CATALINA_TMPDIR: /usr/local/tomcat/temp Using JRE_HOME:
> /usr/lib/jvm/java-17-openjdk-17.0.8.0.7-2.el8.x86_64
> Using CLASSPATH:
> /usr/local/tomcat/bin/*:/usr/local/tomcat/bin/bootstrap.jar:/usr/local/tomc
> at/bin/tomcat-juli.jar
> Using CATALINA_OPTS: -XX:+UseG1GC -Xmx3000m Tomcat started.
>
>
> Not running – No Daemon + No Logs
>
>
> # ./catalina.sh debug
> Using CATALINA_BASE: /usr/local/tomcat
> Using CATALINA_HOME: /usr/local/tomcat
> Using CATALINA_TMPDIR: /usr/local/tomcat/temp Using JAVA_HOME:
> /usr/lib/jvm/java-17-openjdk-17.0.8.0.7-2.el8.x86_64
> Using CLASSPATH:
> /usr/local/tomcat/bin/*:/usr/local/tomcat/bin/bootstrap.jar:/usr/local/tomc
> at/bin/tomcat-juli.jar
> Using CATALINA_OPTS: -XX:+UseG1GC -Xmx3000m invalid option: --add-
> opens=java.base/java.lang=ALL-UNNAMED
>
>
> Usage: jdb   
>
>
> where options include:
>
>
> There are several of the --add-opens statements that cause startup to fail in
> catalina.sh
>
>
> # Add the module start-up parameters required by Tomcat
> JAVA_OPTS="$JAVA_OPTS --add-opens=java.base/java.lang=ALL-
> UNNAMED"
> JAVA_OPTS="$JAVA_OPTS --add-opens=java.base/java.io=ALL-UNNAMED"
> JAVA_OPTS="$JAVA_OPTS --add-opens=java.base/java.util=ALL-
> UNNAMED"
> JAVA_OPTS="$JAVA_OPTS --add-opens=java.base/java.util.concurrent=ALL-
> UNNAMED"
> JAVA_OPTS="$JAVA_OPTS --add-opens=java.rmi/sun.rmi.transport=ALL-
> UNNAMED"
>
>
>
>
> Not sure what to do.
>
>
> -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: [External]Re: Tomcat 10 on RHEL 8 with Java 17