RE: Database Connection Requests Initiated but Not Sent on the Wire (Some, Not All)

[Eric Robinson]

Hi Mark,


> -Original Message-
> From: Mark Thomas 
> Sent: Wednesday, May 29, 2024 5:35 AM
> To: users@tomcat.apache.org
> Subject: Re: Database Connection Requests Initiated but Not Sent on the Wire
> (Some, Not All)
>
> On 29/05/2024 10:26, Mark Thomas wrote:
> > On 28/05/2024 16:26, Eric Robinson wrote:
> >
> > 
> >
> >> Took a bunch of thread and heap dumps during today's painful debacle.
> >> Will send a link to those as soon as I can.
> >
> > Thanks. I have them. I have taken a look and I am starting to form a
> > theory. To help with that I have a couple of questions.
>
> Scratch that. I've found some further information in the data Eric sent me 
> off-
> list and I am now pretty sure what is going on.
>
> There are multiple web applications deployed on the servers. I assume there 
> are
> related but it actually doesn't matter.
>
> At least one application is using the "new" MySQL JDBC driver:
> com.mysql.cj.jdbc.Driver
>
> At least one application is using the "old" MySQL JDBC driver:
> com.mysql.jdbc.Driver
>
>
> (I've told Eric off-list which application is using which).
>
> There are, therefore, two drivers registered with the java.sql.DriverManager
>
>
> The web applications are not using connection pooling. Or, if they are using 
> it,
> they are using it very inefficiently. The result is that there is a high 
> volume of
> calls to create new database connections.
>
> This is problem number 1. Creating a database connection is expensive.
> That is why the concept of database connection pooling was created.
>
>
> When a new connection is created, java.sql.DriverManager iterates over the 
> list
> of registered drivers and
> - tests to see if the current class loader can see the driver
> - if yes, tests to see if that driver can service the connection url
> - if yes, use it and exit
> - go on to the next driver in the list and repeat
>
> The test to see if the current class loader can use the driver is, 
> essentially, to
> call Class.forName(driver.getClass(), true, classloader)
>
> And that is problem number 2. That check is expensive if the current class
> loader can't load that driver.
>
>
> It is also problem number 3. The reason it is expensive is that class
> loaders don't cache misses so if a web application has a large number of
> JARs, they all get scanned every time the DriverManager tries to create
> a new connection.
>
>
> The slowness occurs in the web application that depends on the second
> JDBC driver in DriverManager's list. When a request that requires a
> database connection is received, there is a short delay while the web
> application tries, and fails, to load the first JDBC driver in the list.
> Class loading is synchronized on class name being loaded so if any other
> requests also need a database connection, they have to wait for this
> request to finish the search for the JDBC driver before they can
> continue. This creates a bottleneck. Requests are essentially rate
> limited to 1 request that requires a database connection per however
> long it takes to scan every JAR in the web application for a class that
> isn't there. If the average rate of requests exceeds this rate limit
> then a queue is going to build up and it won't subside until the average
> rate of requests falls below this rate limit.
>
>
>
> Problem number 1 is an application issue. It should be using pooling. It
> seems unlikely that we'll see a solution from the application vendor and
> - even if the vendor does commit to a fix - I suspect it will take months.
>
>
> Problem number 2 is a JRE issue. I think there are potentially more
> efficient ways to perform that check but that needs research as things
> like OSGI and JPMS make class loading more complicated.
>
>
> Problem number 3 is a Tomcat issue. It should be relatively easy to
> start caching misses (i.e. this class loader cannot load this class) and
> save the time spent repeatedly scanning JARs for a class that isn't there.
>
>
> I intend to wok on a patch for Tomcat that will add caching that should
> speed things up considerably. I hope to have something for Eric to test
> today but it might take me until tomorrow as I have a few other time
> critical things fighting to get tot he top of my TODO list at the moment.
>
>
> Moving the JDBC driver JARs from WEB-INF/lib to $CATALINA_BASE/lib may
> also be a short-term fix but is likely to create problems if the same
> JAR ever exists in both locations at the same time.
>
>
> Mark
>

That's some great sleuthing and the explanation makes a ton of sense. It leaves 
me with a couple of questions.

If you are correct, then it follows that historic activity has been hovering 
dangerously near the threshold where this symptom would manifest. Within the 
past month, an unknown change in the system climate now causes an uptick in the 
number of DB requests/second at roughly the same time daily (with occasional 
exceptions) and the system begins to trip over its own feet. I haven't seen 

Re: Query integrating Apache Tomcat with Azure Sentinel via a data connector on Azure Sentinel

[Olaf Kock]

Hi Kele,

On 29.05.24 13:53, Kele Masemola wrote:

Good day ,

We are trying to integrate Apache Tomcat with Azure Sentinel, we realized that 
the agent that needs to be installed on our Apache Tomcat machines will be 
deprecated in August 2024 and as such we would like to find out if there is 
another agent that will be provided to Microsoft as part of the Apache Tomcat 
data connector on Azure Sentinel?

If there will be a new agent provided, please advise on timeframes of when it 
will be available on Azure Sentinel.

If there is no new agent that will be provided from an Apache Tomcat 
perspective, could you please advise if the current available agent on Azure 
Sentinel will still be able to ingest logs accordingly after it has been 
deprecated?


The documentation
(https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/data-connectors/apache-tomcat.md)
and your statement ("needs to be installed") looks like this is not a
Tomcat feature, but an extra plugin by Microsoft (in fact, the
documentation lists: "Supported by: Microsoft Corporation".

From that point of view, I don't expect anything to be provided "from
an Apache Tomcat perspective". It has never been provided in the first
place. You might find more information in Microsoft's statements about
the deprecation of their own component, and what they recommend to use
instead.

(Somebody correct me if I'm wrong and there's something on the roadmap,
or already in and I've missed it)

Olaf

Query integrating Apache Tomcat with Azure Sentinel via a data connector on Azure Sentinel

[Kele Masemola]

Good day ,

We are trying to integrate Apache Tomcat with Azure Sentinel, we realized that 
the agent that needs to be installed on our Apache Tomcat machines will be 
deprecated in August 2024 and as such we would like to find out if there is 
another agent that will be provided to Microsoft as part of the Apache Tomcat 
data connector on Azure Sentinel?

If there will be a new agent provided, please advise on timeframes of when it 
will be available on Azure Sentinel.

If there is no new agent that will be provided from an Apache Tomcat 
perspective, could you please advise if the current available agent on Azure 
Sentinel will still be able to ingest logs accordingly after it has been 
deprecated?

Your assistance with this will be greatly appreciated.

Regards
Kele Masemola

Re: Database Connection Requests Initiated but Not Sent on the Wire (Some, Not All)

[Mark Thomas]

On 29/05/2024 10:26, Mark Thomas wrote:

On 28/05/2024 16:26, Eric Robinson wrote:



Took a bunch of thread and heap dumps during today's painful debacle. 
Will send a link to those as soon as I can.


Thanks. I have them. I have taken a look and I am starting to form a 
theory. To help with that I have a couple of questions.


Scratch that. I've found some further information in the data Eric sent 
me off-list and I am now pretty sure what is going on.


There are multiple web applications deployed on the servers. I assume 
there are related but it actually doesn't matter.


At least one application is using the "new" MySQL JDBC driver:
com.mysql.cj.jdbc.Driver

At least one application is using the "old" MySQL JDBC driver:
com.mysql.jdbc.Driver


(I've told Eric off-list which application is using which).

There are, therefore, two drivers registered with the java.sql.DriverManager


The web applications are not using connection pooling. Or, if they are 
using it, they are using it very inefficiently. The result is that there 
is a high volume of calls to create new database connections.


This is problem number 1. Creating a database connection is expensive. 
That is why the concept of database connection pooling was created.



When a new connection is created, java.sql.DriverManager iterates over 
the list of registered drivers and

- tests to see if the current class loader can see the driver
- if yes, tests to see if that driver can service the connection url
- if yes, use it and exit
- go on to the next driver in the list and repeat

The test to see if the current class loader can use the driver is, 
essentially, to call Class.forName(driver.getClass(), true, classloader)


And that is problem number 2. That check is expensive if the current 
class loader can't load that driver.



It is also problem number 3. The reason it is expensive is that class 
loaders don't cache misses so if a web application has a large number of 
JARs, they all get scanned every time the DriverManager tries to create 
a new connection.



The slowness occurs in the web application that depends on the second 
JDBC driver in DriverManager's list. When a request that requires a 
database connection is received, there is a short delay while the web 
application tries, and fails, to load the first JDBC driver in the list. 
Class loading is synchronized on class name being loaded so if any other 
requests also need a database connection, they have to wait for this 
request to finish the search for the JDBC driver before they can 
continue. This creates a bottleneck. Requests are essentially rate 
limited to 1 request that requires a database connection per however 
long it takes to scan every JAR in the web application for a class that 
isn't there. If the average rate of requests exceeds this rate limit 
then a queue is going to build up and it won't subside until the average 
rate of requests falls below this rate limit.




Problem number 1 is an application issue. It should be using pooling. It 
seems unlikely that we'll see a solution from the application vendor and 
- even if the vendor does commit to a fix - I suspect it will take months.



Problem number 2 is a JRE issue. I think there are potentially more 
efficient ways to perform that check but that needs research as things 
like OSGI and JPMS make class loading more complicated.



Problem number 3 is a Tomcat issue. It should be relatively easy to 
start caching misses (i.e. this class loader cannot load this class) and 
save the time spent repeatedly scanning JARs for a class that isn't there.



I intend to wok on a patch for Tomcat that will add caching that should 
speed things up considerably. I hope to have something for Eric to test 
today but it might take me until tomorrow as I have a few other time 
critical things fighting to get tot he top of my TODO list at the moment.



Moving the JDBC driver JARs from WEB-INF/lib to $CATALINA_BASE/lib may 
also be a short-term fix but is likely to create problems if the same 
JAR ever exists in both locations at the same time.



Mark

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

Re: Database Connection Requests Initiated but Not Sent on the Wire (Some, Not All)

[Mark Thomas]

On 28/05/2024 16:26, Eric Robinson wrote:




Took a bunch of thread and heap dumps during today's painful debacle. Will send 
a link to those as soon as I can.


Thanks. I have them. I have taken a look and I am starting to form a 
theory. To help with that I have a couple of questions.


1. Could you tell me where the JDBC driver JAR is located. Is it in 
WEB-INF/lib for the web application(s) or is it in $CATALINA_BASE/lib ?


2. How big is WEB-INF/lib for the web application(s)? How many JAR files 
and what is the total size on disk of that directory?


3. Would you be prepared to run Tomcat in production with a binary patch 
(against 9.0.80). This would involve placing one or more class files in 
the right directory structure under $CATALINA_BASE/lib either to collect 
additional debug logging or to test a potential fix.




Mark

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

Re: PersistentManager and ClassNotFoundException

[Christopher Schultz]

Jakub,

On 5/24/24 09:31, Jakub Królikowski wrote:

On Fri, May 24, 2024 at 11:23 AM Mark Thomas  wrote:


Can you provide the simplest web application (with source) that
replications the problem?

Mark


On 23/05/2024 23:45, Jakub Królikowski wrote:

Hi,

I'm working with Tomcat 10.1.

When a user starts using the store in my web application, I save the
ShopCart object on the "cart" session attribute.
I want the "cart" attributes to return to the session after restarting

the

app.


To enable session persistence I added



to the Context. It loads the StandardManager.

And this works fine - after reload / restart the object "ShopCart" is

back

in the session.



I want to experiment with PersistentManager. Tomcat docs says: "
The persistence across restarts provided by the *StandardManager* is a
simpler implementation than that provided by the *PersistentManager*. If
robust, production quality persistence across restarts is required then

the

*PersistentManager* should be used with an appropriate configuration.

"

I hope for a Listener of deserialization of the session attributes.

The new Manager configuration looks like this:







But it doesn't work. After restart I get this exception:


java.lang.ClassNotFoundException: ShopCart

at


org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1332)


at


org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1144)


at java.base/java.lang.Class.forName0(Native Method)

at java.base/java.lang.Class.forName(Class.java:534)

at java.base/java.lang.Class.forName(Class.java:513)

at


org.apache.catalina.util.CustomObjectInputStream.resolveClass(CustomObjectInputStream.java:158)


at
java.base/java.io

.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:2061)


at
java.base/java.io

.ObjectInputStream.readClassDesc(ObjectInputStream.java:1927)


at
java.base/java.io

.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2252)


at
java.base/java.io

.ObjectInputStream.readObject0(ObjectInputStream.java:1762)


at
java.base/java.io

.ObjectInputStream.readObject(ObjectInputStream.java:540)


at
java.base/java.io

.ObjectInputStream.readObject(ObjectInputStream.java:498)


at


org.apache.catalina.session.StandardSession.doReadObject(StandardSession.java:1198)


at


org.apache.catalina.session.StandardSession.readObjectData(StandardSession.java:831)


at org.apache.catalina.session.FileStore.load(FileStore.java:203)

at

org.apache.catalina.session.StoreBase.processExpires(StoreBase.java:138)


at


org.apache.catalina.session.PersistentManagerBase.processExpires(PersistentManagerBase.java:409)


at


org.apache.catalina.session.ManagerBase.backgroundProcess(ManagerBase.java:587)


at


org.apache.catalina.core.StandardContext.backgroundProcess(StandardContext.java:4787)


at


org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1172)


at


org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1176)


at


org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1176)


at


org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1154)


at


java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)






at


java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:358)


at


java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)


at


java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)


at


java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)


at


org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:63)


at java.base/java.lang.Thread.run(Thread.java:1583)


I guess this means that the two managers use ClassLoader differently.
How to get the PersistentManager to work in this case?

Best regards,
--
Jakub Królikowski



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




Hi Mark,
It seems to me that this can be tested on any application.
In Tomcat 10.1, if any session attribute is an instance of a new public
class (unknown to Tomcat and to Tomcat class loader), implementing
java.io.Serializable,
then on reloading the application PersistanceManager (configured as in the
first message) crashes with ClassNotFoundException. StandardManager works.
I don't know if this problem occurred in earlier versions of Tomcat.

If you fail to reproduce this bug, let me know, I will prepare a simple web
app.


Where is your  configuration located? It *should* be inside 
your  located in META-INF/context.xml in your web application. 
If it's in there, then 

RE: Database Connection Requests Initiated but Not Sent on the Wire (Some, Not All)

[Eric Robinson]

Hi Mark,

See comments below.


> -Original Message-
> From: Mark Thomas 
> Sent: Tuesday, May 28, 2024 9:32 AM
> To: Tomcat Users List 
> Subject: Re: Database Connection Requests Initiated but Not Sent on the Wire
> (Some, Not All)
>
> Hi Eric,
>
> Follow-up observsations and comments in-line.
>
> >> What time does this problem start?
> >
> > It typically starts around 9:15 am EDT and goes until around 10:30 am.
>
> Does that match the time of highest request load from the customer?
> Rather than a spike, I'm wondering if the problem is triggered once load
> exceeds some threshold.
>

My nginx proxy console only shows live activity and does not keep a history, 
but I can probably script something to parse the localhost_access logs and 
graph request counts on a per-minute basis. Will work on that.

> > We finished and implemented the script yesterday, so today will be the first
> day that it produces results. It watches the catalina.out file for stuck 
> thread
> detection warnings. When the number of stuck threads exceeds a threshold,
> then it starts doing thread dumps every 60 seconds until the counts drops back
> down below the threshold. The users typically do not complain of slowness 
> until
> the stuck thread count exceeds 20, and during that time the threads often take
> up to a minute or more to complete. It's too late today to change the timings,
> but if it does not produce any actionable intel, we can adjust them tonight.
>
> Lets see what that produces and go from there.
>

Took a bunch of thread and heap dumps during today's painful debacle. Will send 
a link to those as soon as I can.

> > The vendor claims that the feature uses a different server and does not send
> requests to the slow ones, so it has been re-enabled at the customer's 
> request.
> We may ask them to disable it again until we get this issue resolved.
>
> Noted.
>
> > This customer sends about 1.5 million requests to each load-balanced
> > server during a typical production day. Most other customers send much
> > less, often only a fraction of that. However, at least one customer
> > sends about 2 million to the same server, and they don't see the
> > problem. (I will check if they have the AI feature enabled.)
>
> Hmm. Whether that other customer has the AI feature enabled would be an
> interesting data point.

I will ask them right after I send this message. They are usually a little slow 
to respond.

>
> >> Can we see the full stack trace please.
> >
> > Here's one example.
>
> 
>
> >  java.lang.Throwable
> >  at
> org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoa
> derBase.java:1252)
> >  at
> > org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClass
> > LoaderBase.java:1220)
>
> 
>
> That is *very* interesting. That is the start of a synch block in the class 
> loader. It
> should complete quickly. The full thread dump should tell us what is holding 
> the
> lock. If we are lucky we'll be able to tell why the lock is being held for so 
> long.
>
> We might need to reduce the time between thread dumps to figure out what
> the thread that is blocking everything is doing. We'll see.
>
> > The app has DB connection details in two places. First, it uses a database
> connection string in a .properties file, as follows. This string handles most
> connections to the DB.
> >
> > mobiledoc.DBUrl=jdbc:mysql://ha52a:5791
> >
> mobiledoc.DBName=mobiledoc_791?useSSL=false=rou
> nd
> >
> =false=true
> > esOnException=true=false=tru
> > e=true
> > mobiledoc.DBUser=
> > mobiledoc.DBPassword=
>
> OK. That seems unlikely to be using connection pooling although the 
> application
> might be pooling internally.
>

Based on lots of previous observation, I don't think they are. The comms 
between the app and DB are choppy, with only about 1-5 queries per TCP 
connection. If they are pooling, they are not doing it aggressively.

> > It also has second DB config specifically for a drug database.
> >
> > 
> >
> >
> >  
> >  
> >  
> >  c:\out.log
> >
> >
> >
> >
> >
> >  
> >
> INSERT_CONTEXT_FACTORY FACTORY>
> >  INSERT_JNDI_URL
> >  INSERT_USER_NAME
> >  INSERT_PASSWORD
> >  INSERT_LOOKUP_NAME
> >  com.mysql.jdbc.Driver
> >
> jdbc:mysql://dbclust54:5791/medispan?sessionVariables=wait_timeout=2
> 8800,interactive_timeout=28800
> >  redacted
> >  redacted
> >  10
> >  5000
> >
> >
> >
> >
> >  true
> >  0
> >  1800
> >
> > 
>
> Hmm. There is a pool size setting there but we can't tell if it is being used.
>
> >> Is that Tomcat 9.0.80 as provided by the ASF?
>
> An explicit answer to this question would be helpful.
>

Didn't mean to seem evasive. Yes, it's from the ASF.


> In terms of the way forward, we need to see to thread dumps when the problem
> is happening to figure out where the blockage is happening and
> (hopefully) why.
>
> Mark

Re: Database Connection Requests Initiated but Not Sent on the Wire (Some, Not All)

[Mark Thomas]

Hi Eric,

Follow-up observsations and comments in-line.


What time does this problem start?


It typically starts around 9:15 am EDT and goes until around 10:30 am.


Does that match the time of highest request load from the customer? 
Rather than a spike, I'm wondering if the problem is triggered once load 
exceeds some threshold.



We finished and implemented the script yesterday, so today will be the first 
day that it produces results. It watches the catalina.out file for stuck thread 
detection warnings. When the number of stuck threads exceeds a threshold, then 
it starts doing thread dumps every 60 seconds until the counts drops back down 
below the threshold. The users typically do not complain of slowness until the 
stuck thread count exceeds 20, and during that time the threads often take up 
to a minute or more to complete. It's too late today to change the timings, but 
if it does not produce any actionable intel, we can adjust them tonight.


Lets see what that produces and go from there.


The vendor claims that the feature uses a different server and does not send 
requests to the slow ones, so it has been re-enabled at the customer's request. 
We may ask them to disable it again until we get this issue resolved.


Noted.


This customer sends about 1.5 million requests to each load-balanced server 
during a typical production day. Most other customers send much less, often 
only a fraction of that. However, at least one customer sends about 2 million 
to the same server, and they don't see the problem. (I will check if they have 
the AI feature enabled.)


Hmm. Whether that other customer has the AI feature enabled would be an 
interesting data point.



Can we see the full stack trace please.


Here's one example.





 java.lang.Throwable
 at 
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1252)
 at 
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1220)




That is *very* interesting. That is the start of a synch block in the 
class loader. It should complete quickly. The full thread dump should 
tell us what is holding the lock. If we are lucky we'll be able to tell 
why the lock is being held for so long.


We might need to reduce the time between thread dumps to figure out what 
the thread that is blocking everything is doing. We'll see.



The app has DB connection details in two places. First, it uses a database 
connection string in a .properties file, as follows. This string handles most 
connections to the DB.

mobiledoc.DBUrl=jdbc:mysql://ha52a:5791
mobiledoc.DBName=mobiledoc_791?useSSL=false=round=false=true=true=false=true=true
mobiledoc.DBUser=
mobiledoc.DBPassword=


OK. That seems unlikely to be using connection pooling although the 
application might be pooling internally.



It also has second DB config specifically for a drug database.


   
   
 
 
 
 c:\out.log
   
   
   
   
   
 
 INSERT_CONTEXT_FACTORY
 INSERT_JNDI_URL
 INSERT_USER_NAME
 INSERT_PASSWORD
 INSERT_LOOKUP_NAME
 com.mysql.jdbc.Driver
 
jdbc:mysql://dbclust54:5791/medispan?sessionVariables=wait_timeout=28800,interactive_timeout=28800
 redacted
 redacted
 10
 5000
   
   
   
   
 true
 0
 1800
   



Hmm. There is a pool size setting there but we can't tell if it is being 
used.



Is that Tomcat 9.0.80 as provided by the ASF?


An explicit answer to this question would be helpful.

In terms of the way forward, we need to see to thread dumps when the 
problem is happening to figure out where the blockage is happening and 
(hopefully) why.


Mark

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

RE: Database Connection Requests Initiated but Not Sent on the Wire (Some, Not All)

[Eric Robinson]

Hi Mark,

> -Original Message-
> From: Mark Thomas 
> Sent: Tuesday, May 28, 2024 3:42 AM
> To: users@tomcat.apache.org
> Subject: Re: Database Connection Requests Initiated but Not Sent on the Wire
> (Some, Not All)
>
> Hi Eric,
>
> I have a some follow-up questions in-line. I have also read the other 
> messages in
> this thread and added a couple of additional questions based on what I read in
> those threads.
>
>
> On 26/05/2024 02:58, Eric Robinson wrote:
> > One of our hosting customers is a medical practice using a commercial EMR
> running on tomcat+mysql. It has operated well for over a year, but users have
> suddenly begun experiencing slowness for about an hour at the same time
> every day.
>
> What time does this problem start?
>

It typically starts around 9:15 am EDT and goes until around 10:30 am.

> Does it occur every day of the week including weekends?
>

Most weekdays. There have been 1 or 2 weekdays when it seems that symptom 
inexplicably did not appear. I'm not sure about weekends, as the medical 
practice does not work on those days.

> How does the slowness correlate to:
> - request volume
> - requests to any particular URL(s)?
> - requests from any particular client IP?
> - any other attribute of the request?
>

> (I'm trying to see if there is something about the requests that triggers the
> issue.)
>

We have not seen anything stand out. There are no apparent spikes in request 
volume. The slowness appears to impact all parts of the system (meaning all 
URLs). It manifests for the customer, but we have also seen it when we connect 
to the app internally, behind the firewall and reverse proxy, directly to the 
tomcat server from a workstation connected to the same switch.

> > During the slow times, we've done all the usual troubleshooting to catch the
> problem in the act. The servers have plenty of power and are not overworked.
> There are no slow database queries. Network connectivity is solid. Tomcat has
> plenty of memory. The numbers of database connections, threads, questions,
> queries, etc., remain steady, without spikes. There is no unusual disk 
> latency.
> We have not found any maintenance tasks running during that timeframe.
>
> I would usually suggest taking three thread dumps approximately 5s apart and
> then diffing them to try and spot "slow moving" threads.
>

> I see you have scripted trigger a thread dump when the slowness hits. If you
> haven't already, please configure it to capture (at least) 3 dumps
> ~5 seconds apart.
>
> (If we can spot the slow moving threads we might be able to identify what it 
> is
> that makes them slow moving.)
>

We finished and implemented the script yesterday, so today will be the first 
day that it produces results. It watches the catalina.out file for stuck thread 
detection warnings. When the number of stuck threads exceeds a threshold, then 
it starts doing thread dumps every 60 seconds until the counts drops back down 
below the threshold. The users typically do not complain of slowness until the 
stuck thread count exceeds 20, and during that time the threads often take up 
to a minute or more to complete. It's too late today to change the timings, but 
if it does not produce any actionable intel, we can adjust them tonight.

> > The customer has another load-balanced tomcat instance on a different
> physical server, and the problem happens on that one, too. The servers were
> upgraded with a new kernel and packages on 4/5/24, but the issue did not
> appear until 5/6/24. The vendor enabled a new feature in the customer's
> software, and the problem appeared the next day, but they subsequently
> disabled the feature, and (reportedly) the problem did not go away.
>
> Have you confirmed that the feature really is disabled? Or was it just hidden?
>

The vendor claims that the feature uses a different server and does not send 
requests to the slow ones, so it has been re-enabled at the customer's request. 
We may ask them to disable it again until we get this issue resolved.

> Has this feature been enabled for any other customers? If yes, have they
> experienced similar issues?
>

> (It is suspicious that the issue occurred after the feature was disabled. I 
> wonder
> if some elements of that change (e.g. a database
> change) are still in place and causing issues.)
>

We agree that it is suspicious, but at this point we are forced to give it the 
side-eye. We're not aware of other customers being impacted, but (a) it's a new 
AI-based feature, so not many other customers have it, (b) it is enabled by the 
vendor directly, so we are not in the notification loop, and (c) the problem 
customer is large, with about 800 staff, whereas most other customers are much 
and might not trigger the symptom. Bottom line, we're not *sure*, but we think 
the feature is unrelated, but we'll ask them to disable it anyway.

> > It is worth mentioning that the servers are multi-tenanted, with other
> customers running the same medical 

Re: Database Connection Requests Initiated but Not Sent on the Wire (Some, Not All)

[Mark Thomas]

Hi Eric,

I have a some follow-up questions in-line. I have also read the other 
messages in this thread and added a couple of additional questions based 
on what I read in those threads.



On 26/05/2024 02:58, Eric Robinson wrote:

One of our hosting customers is a medical practice using a commercial EMR 
running on tomcat+mysql. It has operated well for over a year, but users have 
suddenly begun experiencing slowness for about an hour at the same time every 
day.


What time does this problem start?

Does it occur every day of the week including weekends?

How does the slowness correlate to:
- request volume
- requests to any particular URL(s)?
- requests from any particular client IP?
- any other attribute of the request?

(I'm trying to see if there is something about the requests that 
triggers the issue.)



During the slow times, we've done all the usual troubleshooting to catch the 
problem in the act. The servers have plenty of power and are not overworked. 
There are no slow database queries. Network connectivity is solid. Tomcat has 
plenty of memory. The numbers of database connections, threads, questions, 
queries, etc., remain steady, without spikes. There is no unusual disk latency. 
We have not found any maintenance tasks running during that timeframe.


I would usually suggest taking three thread dumps approximately 5s apart 
and then diffing them to try and spot "slow moving" threads.


I see you have scripted trigger a thread dump when the slowness hits. If 
you haven't already, please configure it to capture (at least) 3 dumps 
~5 seconds apart.


(If we can spot the slow moving threads we might be able to identify 
what it is that makes them slow moving.)



The customer has another load-balanced tomcat instance on a different physical 
server, and the problem happens on that one, too. The servers were upgraded 
with a new kernel and packages on 4/5/24, but the issue did not appear until 
5/6/24. The vendor enabled a new feature in the customer's software, and the 
problem appeared the next day, but they subsequently disabled the feature, and 
(reportedly) the problem did not go away.


Have you confirmed that the feature really is disabled? Or was it just 
hidden?


Has this feature been enabled for any other customers? If yes, have they 
experienced similar issues?


(It is suspicious that the issue occurred after the feature was 
disabled. I wonder if some elements of that change (e.g. a database 
change) are still in place and causing issues.)



It is worth mentioning that the servers are multi-tenanted, with other 
customers running the same medical application, but the others do not 
experience the slowdowns, even though they are on the same servers.


How does this customer compare, in terms of volume of requests, to other 
customers that are not experiencing this issue.


Is there anything unique or special about the customer experiencing the 
issue? Do they have some custom settings no-one else uses?


(I am trying to figure out if the issue is load related, customer 
specific or something else).



There are no unusual errors in the tomcat or database server logs, EXCEPT this 
one: Java.sql.DriverManager.getConnection


Can we see the full stack trace please.


During the periods of slowness, we see lots of those errors along with a large 
spike in the number of stuck tomcat threads (from 1 or 2 to as high as 100). It 
seems obvious that the threads are stuck because tomcat is waiting on a 
connection to the database. However, tcpdump shows that connectivity to the 
database is perfect at the network and application layers. There are no 
unanswered SYNs, no retransmissions, no half-open connections, no failures to 
allocate TCP ports, no conntrack messages, and no other indications of system 
resource exhaustion. Every time tomcat requests a connection to the DB, it 
completes in less than 1 ms. Ten thousand connection attempts completed 
successfully in about 15 seconds, with zero failures.


It sounds like things might be getting stuck somewhere in or near the 
JDBC driver.


Can you provide the exact version of the JDBC driver you are using?

Can you provide the full database configuration from context.xml (or 
wherever it is configured). Please redact sensitive information such as 
passwords.



We are forced to conclude that some database connection requests are being 
initiated but are not being sent on the wire. The problem seems to be in the 
interaction between tomcat and the database driver, or in the driver itself.


I agree.


Unfortunately, the application vendor is taking the "it's your infrastructure" 
position without providing any evidence or offering suggestions for configuration changes,


I'm sorry to hear that. We'll do what we can to help.


other than to deploy more tomcat instances, which is just shooting in the dark. 
They don't know why the software is throwing 
java.sql.DriverManager.getConnection errors (even though it's their code), and 

RE: Database Connection Requests Initiated but Not Sent on the Wire (Some, Not All)

[Eric Robinson]

Hi Chuck,

> -Original Message-
> From: Chuck Caldarale 
> Sent: Sunday, May 26, 2024 2:21 PM
> To: Tomcat Users List 
> Subject: Re: Database Connection Requests Initiated but Not Sent on the Wire
> (Some, Not All)
>
>
> > On May 25, 2024, at 20:58, Eric Robinson  wrote:
> >
> > One of our hosting customers is a medical practice using a commercial EMR
> running on tomcat+mysql. It has operated well for over a year, but users have
> suddenly begun experiencing slowness for about an hour at the same time
> every day. During the slow times, we've done all the usual troubleshooting to
> catch the problem in the act. The servers have plenty of power and are not
> overworked. There are no slow database queries. Network connectivity is solid.
> Tomcat has plenty of memory. The numbers of database connections, threads,
> questions, queries, etc., remain steady, without spikes. There is no unusual 
> disk
> latency. We have not found any maintenance tasks running during that
> timeframe.
>
>
> 
>
>
> > There are no unusual errors in the tomcat or database server logs, EXCEPT
> this one: Java.sql.DriverManager.getConnection
>
>
> 
>
>
> > During the periods of slowness, we see lots of those errors along with a 
> > large
> spike in the number of stuck tomcat threads (from 1 or 2 to as high as 100). 
> It
> seems obvious that the threads are stuck because tomcat is waiting on a
> connection to the database.
>
>
> 
>
>
> > We are forced to conclude that some database connection requests are being
> initiated but are not being sent on the wire.
>
>
> Could the DB server be out of ports? (Seems unlikely, based on your debugging
> so far.)
>

We have not seen any indication of that.

> Any chance that the Tomcat process is running out of file descriptors? Or 
> ports?
>

Likewise, no indications of that.

> Can you force a garbage collection (e.g., with jconsole or similar tool) 
> during a
> slow period? If there is some limit on an OS-level resource that’s being 
> reached,
> a GC may be able to delete the Java objects that are tying up the underlying
> resources.

GC is on my list of things to try.

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

Disclaimer : This email and any files transmitted with it are confidential and 
intended solely for intended recipients. If you are not the named addressee you 
should not disseminate, distribute, copy or alter this email. Any views or 
opinions presented in this email are solely those of the author and might not 
represent those of Physician Select Management. Warning: Although Physician 
Select Management has taken reasonable precautions to ensure no viruses are 
present in this email, the company cannot accept responsibility for any loss or 
damage arising from the use of this email or attachments.

RE: Database Connection Requests Initiated but Not Sent on the Wire (Some, Not All)

[Eric Robinson]

Hi Thomas,


> -Original Message-
> From: Thomas Hoffmann (Speed4Trade GmbH)
> 
> Sent: Sunday, May 26, 2024 3:30 PM
> To: Tomcat Users List 
> Subject: AW: Database Connection Requests Initiated but Not Sent on the Wire
> (Some, Not All)
>
> Hello,
>
> > -Ursprüngliche Nachricht-
> > Von: Chuck Caldarale 
> > Gesendet: Sonntag, 26. Mai 2024 21:21
> > An: Tomcat Users List 
> > Betreff: Re: Database Connection Requests Initiated but Not Sent on
> > the Wire (Some, Not All)
> >
> >
> > > On May 25, 2024, at 20:58, Eric Robinson 
> wrote:
> > >
> > > One of our hosting customers is a medical practice using a
> > > commercial EMR
> > running on tomcat+mysql. It has operated well for over a year, but
> > users have suddenly begun experiencing slowness for about an hour at
> > the same time every day. During the slow times, we've done all the
> > usual troubleshooting to catch the problem in the act. The servers
> > have plenty of power and are not overworked. There are no slow database
> queries. Network connectivity is solid.
> > Tomcat has plenty of memory. The numbers of database connections,
> > threads, questions, queries, etc., remain steady, without spikes.
> > There is no unusual disk latency. We have not found any maintenance
> > tasks running during that timeframe.
> >
> >
> > 
> >
> >
> > > There are no unusual errors in the tomcat or database server logs,
> > > EXCEPT
> > this one: Java.sql.DriverManager.getConnection
> >
> >
> > 
> >
> >
> > > During the periods of slowness, we see lots of those errors along
> > > with a large
> > spike in the number of stuck tomcat threads (from 1 or 2 to as high as
> > 100). It seems obvious that the threads are stuck because tomcat is
> > waiting on a connection to the database.
> >
> >
> > 
> >
> >
> > > We are forced to conclude that some database connection requests are
> > > being
> > initiated but are not being sent on the wire.
> >
> >
> > Could the DB server be out of ports? (Seems unlikely, based on your
> > debugging so far.)
> >
> > Any chance that the Tomcat process is running out of file descriptors? Or
> ports?
> >
> > Can you force a garbage collection (e.g., with jconsole or similar
> > tool) during a slow period? If there is some limit on an OS-level
> > resource that’s being reached, a GC may be able to delete the Java
> > objects that are tying up the underlying resources.
> >
> >   - Chuck
> >
>
>
> On the client side, the TCP connections are kept in a wait-state for usually 2
> minutes as far as I know.
> Maybe you can check how many are in this state.
>

On our server, we set things much lower to allow faster recycling of TCP 
connections...

net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_tw_reuse = 1

> If the application doesn’t use connection pooling, then this can be the 
> problem
> itself too.

During peak production, there are a total of around 20,000 connections in 
various states, mostly TIME_WAIT. The port range is 5000-6.
Dmesg, journalcrl, and the messages file don't show any errors about running 
out of ports or file handles.


> TCP handshakes and logon process take a while and for performance reasons,
> DB connections are usually pooled.
>
> A stacktrace might help to see what java is doing when it enters this blocking
> state.
> Maybe you can provide a stack when the app starts blocking.
>

We are writing a script to watch for stuck threads to exceed a threshold, and 
do a thread dump when that happens.

> Greetings,
> Thomas
Disclaimer : This email and any files transmitted with it are confidential and 
intended solely for intended recipients. If you are not the named addressee you 
should not disseminate, distribute, copy or alter this email. Any views or 
opinions presented in this email are solely those of the author and might not 
represent those of Physician Select Management. Warning: Although Physician 
Select Management has taken reasonable precautions to ensure no viruses are 
present in this email, the company cannot accept responsibility for any loss or 
damage arising from the use of this email or attachments.

AW: Database Connection Requests Initiated but Not Sent on the Wire (Some, Not All)

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

> -Ursprüngliche Nachricht-
> Von: Chuck Caldarale 
> Gesendet: Sonntag, 26. Mai 2024 21:21
> An: Tomcat Users List 
> Betreff: Re: Database Connection Requests Initiated but Not Sent on the Wire
> (Some, Not All)
> 
> 
> > On May 25, 2024, at 20:58, Eric Robinson  wrote:
> >
> > One of our hosting customers is a medical practice using a commercial EMR
> running on tomcat+mysql. It has operated well for over a year, but users have
> suddenly begun experiencing slowness for about an hour at the same time
> every day. During the slow times, we've done all the usual troubleshooting to
> catch the problem in the act. The servers have plenty of power and are not
> overworked. There are no slow database queries. Network connectivity is solid.
> Tomcat has plenty of memory. The numbers of database connections, threads,
> questions, queries, etc., remain steady, without spikes. There is no unusual 
> disk
> latency. We have not found any maintenance tasks running during that
> timeframe.
> 
> 
> 
> 
> 
> > There are no unusual errors in the tomcat or database server logs, EXCEPT
> this one: Java.sql.DriverManager.getConnection
> 
> 
> 
> 
> 
> > During the periods of slowness, we see lots of those errors along with a 
> > large
> spike in the number of stuck tomcat threads (from 1 or 2 to as high as 100). 
> It
> seems obvious that the threads are stuck because tomcat is waiting on a
> connection to the database.
> 
> 
> 
> 
> 
> > We are forced to conclude that some database connection requests are being
> initiated but are not being sent on the wire.
> 
> 
> Could the DB server be out of ports? (Seems unlikely, based on your debugging
> so far.)
> 
> Any chance that the Tomcat process is running out of file descriptors? Or 
> ports?
> 
> Can you force a garbage collection (e.g., with jconsole or similar tool) 
> during a
> slow period? If there is some limit on an OS-level resource that’s being 
> reached,
> a GC may be able to delete the Java objects that are tying up the underlying
> resources.
> 
>   - Chuck
> 


On the client side, the TCP connections are kept in a wait-state for usually 2 
minutes as far as I know.
Maybe you can check how many are in this state.

If the application doesn’t use connection pooling, then this can be the problem 
itself too.
TCP handshakes and logon process take a while and for performance reasons, DB 
connections are usually pooled.

A stacktrace might help to see what java is doing when it enters this blocking 
state.
Maybe you can provide a stack when the app starts blocking.

Greetings, 
Thomas

Re: Database Connection Requests Initiated but Not Sent on the Wire (Some, Not All)

[Chuck Caldarale]

> On May 25, 2024, at 20:58, Eric Robinson  wrote:
> 
> One of our hosting customers is a medical practice using a commercial EMR 
> running on tomcat+mysql. It has operated well for over a year, but users have 
> suddenly begun experiencing slowness for about an hour at the same time every 
> day. During the slow times, we've done all the usual troubleshooting to catch 
> the problem in the act. The servers have plenty of power and are not 
> overworked. There are no slow database queries. Network connectivity is 
> solid. Tomcat has plenty of memory. The numbers of database connections, 
> threads, questions, queries, etc., remain steady, without spikes. There is no 
> unusual disk latency. We have not found any maintenance tasks running during 
> that timeframe.





> There are no unusual errors in the tomcat or database server logs, EXCEPT 
> this one: Java.sql.DriverManager.getConnection





> During the periods of slowness, we see lots of those errors along with a 
> large spike in the number of stuck tomcat threads (from 1 or 2 to as high as 
> 100). It seems obvious that the threads are stuck because tomcat is waiting 
> on a connection to the database.





> We are forced to conclude that some database connection requests are being 
> initiated but are not being sent on the wire.


Could the DB server be out of ports? (Seems unlikely, based on your debugging 
so far.)

Any chance that the Tomcat process is running out of file descriptors? Or ports?

Can you force a garbage collection (e.g., with jconsole or similar tool) during 
a slow period? If there is some limit on an OS-level resource that’s being 
reached, a GC may be able to delete the Java objects that are tying up the 
underlying resources.

  - Chuck


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

RE: Database Connection Requests Initiated but Not Sent on the Wire (Some, Not All)

[Eric Robinson]

Hi Thomas,


> -Original Message-
> From: Thomas Hoffmann (Speed4Trade GmbH)
> 
> Sent: Sunday, May 26, 2024 2:52 AM
> To: Tomcat Users List 
> Subject: AW: Database Connection Requests Initiated but Not Sent on the Wire
> (Some, Not All)
>
> Hello Eric,
>
> > -Ursprüngliche Nachricht-
> > Von: Eric Robinson 
> > Gesendet: Sonntag, 26. Mai 2024 03:59
> > An: users@tomcat.apache.org
> > Betreff: Database Connection Requests Initiated but Not Sent on the
> > Wire (Some, Not All)
> >
> > One of our hosting customers is a medical practice using a commercial
> > EMR running on tomcat+mysql. It has operated well for over a year, but
> > users have suddenly begun experiencing slowness for about an hour at
> > the same time every day. During the slow times, we've done all the
> > usual troubleshooting to catch the problem in the act. The servers
> > have plenty of power and are not overworked. There are no slow database
> queries. Network connectivity is solid.
> > Tomcat has plenty of memory. The numbers of database connections,
> > threads, questions, queries, etc., remain steady, without spikes.
> > There is no unusual disk latency. We have not found any maintenance
> > tasks running during that timeframe.
> >
> > The customer has another load-balanced tomcat instance on a different
> > physical server, and the problem happens on that one, too. The servers
> > were upgraded with a new kernel and packages on 4/5/24, but the issue
> > did not appear until 5/6/24. The vendor enabled a new feature in the
> > customer's software, and the problem appeared the next day, but they
> > subsequently disabled the feature, and (reportedly) the problem did
> > not go away. It is worth mentioning that the servers are
> > multi-tenanted, with other customers running the same medical
> > application, but the others do not experience the slowdowns, even though
> they are on the same servers.
> >
> > There are no unusual errors in the tomcat or database server logs,
> > EXCEPT this
> > one: Java.sql.DriverManager.getConnection
> >
> > During the periods of slowness, we see lots of those errors along with
> > a large spike in the number of stuck tomcat threads (from 1 or 2 to as
> > high as 100). It seems obvious that the threads are stuck because
> > tomcat is waiting on a connection to the database. However, tcpdump
> > shows that connectivity to the database is perfect at the network and
> > application layers. There are no unanswered SYNs, no retransmissions,
> > no half-open connections, no failures to allocate TCP ports, no
> > conntrack messages, and no other indications of system resource
> > exhaustion. Every time tomcat requests a connection to the DB, it
> > completes in less than 1 ms. Ten thousand connection attempts completed
> successfully in about 15 seconds, with zero failures.
> >
> > We are forced to conclude that some database connection requests are
> > being initiated but are not being sent on the wire. The problem seems
> > to be in the interaction between tomcat and the database driver, or in the
> driver itself.
> > Unfortunately, the application vendor is taking the "it's your 
> > infrastructure"
> > position without providing any evidence or offering suggestions for
> > configuration changes, other than to deploy more tomcat instances,
> > which is just shooting in the dark. They don't know why the software
> > is throwing java.sql.DriverManager.getConnection errors (even though
> > it's their code), and they've relegated the investigation to us.
> >
> > Any advice from the community would be greatly appreciated.
> >
> > RHEL 8.9, kernel 4.18.0-513.18.1.el8_9.x86_64 Apache Tomcat/9.0.80,
> > JVM
> > 1.8.0_372-b07
> >
> > (The tomcat and JVM versions are the ones recommended by the vendor.)
> >
> > We're standing by to provide whatever other information the community
> > may need.
> >
> > Thanks tons!
> >
> > -Eric
>
> The database connections are usually pooled.
> If the pool is exhausted, the thread will wait till a connection is returned 
> to the
> pool which can be reused.
> Do you use connection pooling?
> How does the configuration look like?
> Do you monitor the pool usage?
>
> In general, it doesn’t look like a Tomcat issue per sé.
>
> Greetings,
> Thomas
>

I have asked the vendor that question several times, but their technicians have 
never provided a clear answer. Most of the time they have not even understood 
the question. If pooling were enabled, I would expect to see maxTotal or 
maxIdle tags in a context.xml or web.xml file somewhere in the system, but they 
are not there. The database connection details are stored in a file named 
myapp.properties (renamed here to protect the identity of the vendor, as I 
imagine they visit this forum). The string looks like this:

myapp.DBName=mydb?useSSL=false=round=false=true=true=false=true=true

In WireShark, I see thousands of connections, and from 1 to several SQL queries 
being issued over the same connection before it closes. 

AW: Database Connection Requests Initiated but Not Sent on the Wire (Some, Not All)

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello Eric,

> -Ursprüngliche Nachricht-
> Von: Eric Robinson 
> Gesendet: Sonntag, 26. Mai 2024 03:59
> An: users@tomcat.apache.org
> Betreff: Database Connection Requests Initiated but Not Sent on the Wire
> (Some, Not All)
> 
> One of our hosting customers is a medical practice using a commercial EMR
> running on tomcat+mysql. It has operated well for over a year, but users have
> suddenly begun experiencing slowness for about an hour at the same time
> every day. During the slow times, we've done all the usual troubleshooting to
> catch the problem in the act. The servers have plenty of power and are not
> overworked. There are no slow database queries. Network connectivity is solid.
> Tomcat has plenty of memory. The numbers of database connections, threads,
> questions, queries, etc., remain steady, without spikes. There is no unusual 
> disk
> latency. We have not found any maintenance tasks running during that
> timeframe.
> 
> The customer has another load-balanced tomcat instance on a different
> physical server, and the problem happens on that one, too. The servers were
> upgraded with a new kernel and packages on 4/5/24, but the issue did not
> appear until 5/6/24. The vendor enabled a new feature in the customer's
> software, and the problem appeared the next day, but they subsequently
> disabled the feature, and (reportedly) the problem did not go away. It is 
> worth
> mentioning that the servers are multi-tenanted, with other customers running
> the same medical application, but the others do not experience the slowdowns,
> even though they are on the same servers.
> 
> There are no unusual errors in the tomcat or database server logs, EXCEPT this
> one: Java.sql.DriverManager.getConnection
> 
> During the periods of slowness, we see lots of those errors along with a large
> spike in the number of stuck tomcat threads (from 1 or 2 to as high as 100). 
> It
> seems obvious that the threads are stuck because tomcat is waiting on a
> connection to the database. However, tcpdump shows that connectivity to the
> database is perfect at the network and application layers. There are no
> unanswered SYNs, no retransmissions, no half-open connections, no failures to
> allocate TCP ports, no conntrack messages, and no other indications of system
> resource exhaustion. Every time tomcat requests a connection to the DB, it
> completes in less than 1 ms. Ten thousand connection attempts completed
> successfully in about 15 seconds, with zero failures.
> 
> We are forced to conclude that some database connection requests are being
> initiated but are not being sent on the wire. The problem seems to be in the
> interaction between tomcat and the database driver, or in the driver itself.
> Unfortunately, the application vendor is taking the "it's your infrastructure"
> position without providing any evidence or offering suggestions for
> configuration changes, other than to deploy more tomcat instances, which is
> just shooting in the dark. They don't know why the software is throwing
> java.sql.DriverManager.getConnection errors (even though it's their code), and
> they've relegated the investigation to us.
> 
> Any advice from the community would be greatly appreciated.
> 
> RHEL 8.9, kernel 4.18.0-513.18.1.el8_9.x86_64 Apache Tomcat/9.0.80, JVM
> 1.8.0_372-b07
> 
> (The tomcat and JVM versions are the ones recommended by the vendor.)
> 
> We're standing by to provide whatever other information the community may
> need.
> 
> Thanks tons!
> 
> -Eric

The database connections are usually pooled.
If the pool is exhausted, the thread will wait till a connection is returned to 
the pool which can be reused.
Do you use connection pooling?
How does the configuration look like?
Do you monitor the pool usage?

In general, it doesn’t look like a Tomcat issue per sé.

Greetings,
Thomas

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

Database Connection Requests Initiated but Not Sent on the Wire (Some, Not All)

[Eric Robinson]

One of our hosting customers is a medical practice using a commercial EMR 
running on tomcat+mysql. It has operated well for over a year, but users have 
suddenly begun experiencing slowness for about an hour at the same time every 
day. During the slow times, we've done all the usual troubleshooting to catch 
the problem in the act. The servers have plenty of power and are not 
overworked. There are no slow database queries. Network connectivity is solid. 
Tomcat has plenty of memory. The numbers of database connections, threads, 
questions, queries, etc., remain steady, without spikes. There is no unusual 
disk latency. We have not found any maintenance tasks running during that 
timeframe.

The customer has another load-balanced tomcat instance on a different physical 
server, and the problem happens on that one, too. The servers were upgraded 
with a new kernel and packages on 4/5/24, but the issue did not appear until 
5/6/24. The vendor enabled a new feature in the customer's software, and the 
problem appeared the next day, but they subsequently disabled the feature, and 
(reportedly) the problem did not go away. It is worth mentioning that the 
servers are multi-tenanted, with other customers running the same medical 
application, but the others do not experience the slowdowns, even though they 
are on the same servers.

There are no unusual errors in the tomcat or database server logs, EXCEPT this 
one: Java.sql.DriverManager.getConnection

During the periods of slowness, we see lots of those errors along with a large 
spike in the number of stuck tomcat threads (from 1 or 2 to as high as 100). It 
seems obvious that the threads are stuck because tomcat is waiting on a 
connection to the database. However, tcpdump shows that connectivity to the 
database is perfect at the network and application layers. There are no 
unanswered SYNs, no retransmissions, no half-open connections, no failures to 
allocate TCP ports, no conntrack messages, and no other indications of system 
resource exhaustion. Every time tomcat requests a connection to the DB, it 
completes in less than 1 ms. Ten thousand connection attempts completed 
successfully in about 15 seconds, with zero failures.

We are forced to conclude that some database connection requests are being 
initiated but are not being sent on the wire. The problem seems to be in the 
interaction between tomcat and the database driver, or in the driver itself. 
Unfortunately, the application vendor is taking the "it's your infrastructure" 
position without providing any evidence or offering suggestions for 
configuration changes, other than to deploy more tomcat instances, which is 
just shooting in the dark. They don't know why the software is throwing 
java.sql.DriverManager.getConnection errors (even though it's their code), and 
they've relegated the investigation to us.

Any advice from the community would be greatly appreciated.

RHEL 8.9, kernel 4.18.0-513.18.1.el8_9.x86_64
Apache Tomcat/9.0.80, JVM 1.8.0_372-b07

(The tomcat and JVM versions are the ones recommended by the vendor.)

We're standing by to provide whatever other information the community may need.

Thanks tons!

-Eric



Disclaimer : This email and any files transmitted with it are confidential and 
intended solely for intended recipients. If you are not the named addressee you 
should not disseminate, distribute, copy or alter this email. Any views or 
opinions presented in this email are solely those of the author and might not 
represent those of Physician Select Management. Warning: Although Physician 
Select Management has taken reasonable precautions to ensure no viruses are 
present in this email, the company cannot accept responsibility for any loss or 
damage arising from the use of this email or attachments.

Re: Deployment using directory

[Mark Thomas]

On 24/05/2024 19:28, Brandie Nickey wrote:

Hi all,

I am curious if there are any cons to deploying a webapp without using a war 
file.


None.

If you deploy a WAR Tomcat will (by default) unpack it and run it from 
the unpacked directory anyway. If you configure Tomcat to run from the 
packed WAR you will get a small performance hit.



 Our web app has just always traditionally been 'unzipped' as a set of folders 
within the Tomcat/webapps/ROOT directory.  However I have been doing some 
troubleshooting using procmon.exe from Sysinternals and it appears that tomcat 
is constantly looking for Root.war file.


Define constantly. I'd expect Tomcat to be checking for a WAR file every 
~15s if autodeploy is enabled.



Not sure if I have something misconfigured or this behavior is just normal?  
The app will start up but does have some issues with loading all features  
(takes 2+ hours) .


If the app is taking 2 hours to start then the app has some serious issues.


Running Tomcat 8.0.43.


Tomcat 8.0.x reached end of support on 30 June 2018.

Tomcat 8.5.x (that replaced 8.0.x) reached end of life on 31 March 2024.

You need to upgrade to at least 9.0.x ASAP. I'd suggest a quick upgrade 
to 9.0.x and then start looking at moving to 10.1.x or even 11.0.x but 
that is a bigger job due to the Java EE -> Jskarta EE repackaging.


Mark

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

Re: PersistentManager and ClassNotFoundException

[Mark Thomas]

On 24/05/2024 14:31, Jakub Królikowski wrote:




Hi Mark,
It seems to me that this can be tested on any application.
In Tomcat 10.1, if any session attribute is an instance of a new public
class (unknown to Tomcat and to Tomcat class loader), implementing
java.io.Serializable,
then on reloading the application PersistanceManager (configured as in the
first message) crashes with ClassNotFoundException. StandardManager works.
I don't know if this problem occurred in earlier versions of Tomcat.

If you fail to reproduce this bug, let me know, I will prepare a simple web
app.

Best regards,

Jakub


Jakub,

The chances of a committer looking at the issue you are seeing are 
significantly higher if you provide a test case that demonstrates the 
issue rather than expecting a committer to write a test case for you 
based on your description.


Mark


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

Re: JVM crashing with caCertificatePath in server.xml

[Andy Arismendi]

Hi Michael,

After re-reading my previous message, I realized it might have been ambiguous 
regarding whether I observed caCertificatePath working with or without your 
first posted file set from 
http://home.apache.org/~michaelo/issues/tomcat/openssl-crash/. To clarify, it 
was indeed your first posted file set that made it work.

The issue I initially encountered on my end was due to some unnecessary copies 
of the original OpenSSL binaries elsewhere in the system path. These copies 
were likely causing different results as they were being loaded without my 
awareness. After removing them I observed Tomcat startup with caCertificatePath 
in server.xml without JVM crash using the original binaries you provided.

I hope this clears up any ambiguity from my previous message.

Thanks!
-Andy

Deployment using directory

[Brandie Nickey]

Hi all,

I am curious if there are any cons to deploying a webapp without using a war 
file.  Our web app has just always traditionally been 'unzipped' as a set of 
folders within the Tomcat/webapps/ROOT directory.  However I have been doing 
some troubleshooting using procmon.exe from Sysinternals and it appears that 
tomcat is constantly looking for Root.war file.  Not sure if I have something 
misconfigured or this behavior is just normal?  The app will start up but does 
have some issues with loading all features  (takes 2+ hours) .

Running Tomcat 8.0.43.

Thank you,
Brandie




Regeneron - Internal

 
This e-mail and any attachment hereto, is intended only for use by the 
addressee(s) named above and may contain legally privileged and/or confidential 
information. If you are not the intended recipient of this e-mail, any 
dissemination, distribution or copying of this email, or any attachment hereto, 
is strictly prohibited. If you receive this email in error please immediately 
notify me by return electronic mail and permanently delete this email and any 
attachment hereto, any copy of this e-mail and of any such attachment, and any 
printout thereof. Finally, please note that only authorized representatives of 
Regeneron Pharmaceuticals, Inc. have the power and authority to enter into 
business dealings with any third party. 

Re: PersistentManager and ClassNotFoundException

[Jakub Królikowski]

On Fri, May 24, 2024 at 11:23 AM Mark Thomas  wrote:

> Can you provide the simplest web application (with source) that
> replications the problem?
>
> Mark
>
>
> On 23/05/2024 23:45, Jakub Królikowski wrote:
> > Hi,
> >
> > I'm working with Tomcat 10.1.
> >
> > When a user starts using the store in my web application, I save the
> > ShopCart object on the "cart" session attribute.
> > I want the "cart" attributes to return to the session after restarting
> the
> > app.
> >
> >
> > To enable session persistence I added
> >
> > 
> >
> > to the Context. It loads the StandardManager.
> >
> > And this works fine - after reload / restart the object "ShopCart" is
> back
> > in the session.
> >
> >
> >
> > I want to experiment with PersistentManager. Tomcat docs says: "
> > The persistence across restarts provided by the *StandardManager* is a
> > simpler implementation than that provided by the *PersistentManager*. If
> > robust, production quality persistence across restarts is required then
> the
> > *PersistentManager* should be used with an appropriate configuration.
> >
> > "
> >
> > I hope for a Listener of deserialization of the session attributes.
> >
> > The new Manager configuration looks like this:
> >
> >  > maxActiveSessions="2" saveOnRestart="true">
> >
> >  > "c:\tomcat10\sessionperm"/>
> >
> > 
> >
> > But it doesn't work. After restart I get this exception:
> >
> >
> > java.lang.ClassNotFoundException: ShopCart
> >
> > at
> >
> org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1332)
> >
> > at
> >
> org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1144)
> >
> > at java.base/java.lang.Class.forName0(Native Method)
> >
> > at java.base/java.lang.Class.forName(Class.java:534)
> >
> > at java.base/java.lang.Class.forName(Class.java:513)
> >
> > at
> >
> org.apache.catalina.util.CustomObjectInputStream.resolveClass(CustomObjectInputStream.java:158)
> >
> > at
> > java.base/java.io
> .ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:2061)
> >
> > at
> > java.base/java.io
> .ObjectInputStream.readClassDesc(ObjectInputStream.java:1927)
> >
> > at
> > java.base/java.io
> .ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2252)
> >
> > at
> > java.base/java.io
> .ObjectInputStream.readObject0(ObjectInputStream.java:1762)
> >
> > at
> > java.base/java.io
> .ObjectInputStream.readObject(ObjectInputStream.java:540)
> >
> > at
> > java.base/java.io
> .ObjectInputStream.readObject(ObjectInputStream.java:498)
> >
> > at
> >
> org.apache.catalina.session.StandardSession.doReadObject(StandardSession.java:1198)
> >
> > at
> >
> org.apache.catalina.session.StandardSession.readObjectData(StandardSession.java:831)
> >
> > at org.apache.catalina.session.FileStore.load(FileStore.java:203)
> >
> > at
> org.apache.catalina.session.StoreBase.processExpires(StoreBase.java:138)
> >
> > at
> >
> org.apache.catalina.session.PersistentManagerBase.processExpires(PersistentManagerBase.java:409)
> >
> > at
> >
> org.apache.catalina.session.ManagerBase.backgroundProcess(ManagerBase.java:587)
> >
> > at
> >
> org.apache.catalina.core.StandardContext.backgroundProcess(StandardContext.java:4787)
> >
> > at
> >
> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1172)
> >
> > at
> >
> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1176)
> >
> > at
> >
> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1176)
> >
> > at
> >
> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1154)
> >
> > at
> >
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
>


> >
> > at
> >
> java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:358)
> >
> > at
> >
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
> >
> > at
> >
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
> >
> > at
> >
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
> >
> > at
> >
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:63)
> >
> > at java.base/java.lang.Thread.run(Thread.java:1583)
> >
> >
> > I guess this means that the two managers use ClassLoader differently.
> > How to get the PersistentManager to work in this case?
> >
> > Best regards,
> > --
> > Jakub Królikowski
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Hi Mark,
It seems to me that this can be tested on any application.
In Tomcat 10.1, if any session attribute is an instance of a new public
class (unknown to Tomcat and to 

Re: PersistentManager and ClassNotFoundException

[Mark Thomas]

Can you provide the simplest web application (with source) that 
replications the problem?


Mark


On 23/05/2024 23:45, Jakub Królikowski wrote:

Hi,

I'm working with Tomcat 10.1.

When a user starts using the store in my web application, I save the
ShopCart object on the "cart" session attribute.
I want the "cart" attributes to return to the session after restarting the
app.


To enable session persistence I added



to the Context. It loads the StandardManager.

And this works fine - after reload / restart the object "ShopCart" is back
in the session.



I want to experiment with PersistentManager. Tomcat docs says: "
The persistence across restarts provided by the *StandardManager* is a
simpler implementation than that provided by the *PersistentManager*. If
robust, production quality persistence across restarts is required then the
*PersistentManager* should be used with an appropriate configuration.

"

I hope for a Listener of deserialization of the session attributes.

The new Manager configuration looks like this:







But it doesn't work. After restart I get this exception:


java.lang.ClassNotFoundException: ShopCart

at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1332)

at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1144)

at java.base/java.lang.Class.forName0(Native Method)

at java.base/java.lang.Class.forName(Class.java:534)

at java.base/java.lang.Class.forName(Class.java:513)

at
org.apache.catalina.util.CustomObjectInputStream.resolveClass(CustomObjectInputStream.java:158)

at
java.base/java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:2061)

at
java.base/java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1927)

at
java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2252)

at
java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1762)

at
java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:540)

at
java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:498)

at
org.apache.catalina.session.StandardSession.doReadObject(StandardSession.java:1198)

at
org.apache.catalina.session.StandardSession.readObjectData(StandardSession.java:831)

at org.apache.catalina.session.FileStore.load(FileStore.java:203)

at org.apache.catalina.session.StoreBase.processExpires(StoreBase.java:138)

at
org.apache.catalina.session.PersistentManagerBase.processExpires(PersistentManagerBase.java:409)

at
org.apache.catalina.session.ManagerBase.backgroundProcess(ManagerBase.java:587)

at
org.apache.catalina.core.StandardContext.backgroundProcess(StandardContext.java:4787)

at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1172)

at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1176)

at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1176)

at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1154)

at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)

at
java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:358)

at
java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)

at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)

at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)

at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:63)

at java.base/java.lang.Thread.run(Thread.java:1583)


I guess this means that the two managers use ClassLoader differently.
How to get the PersistentManager to work in this case?

Best regards,
--
Jakub Królikowski



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

Re: Security Constraints and Session Timeout

[Mark Thomas]

On 23/05/2024 17:01, Jerry Malcolm wrote:
I have some servlets that I can't put security constraints on at the 
web.xml level.  However, deep down in the code there are some places 
that I need a user to be logged in.  My overall UI ensures this all 
works by having certain JSPs with constraints that force the user to log 
in before getting to the servlet.  But if the user spends too much time 
interacting with the servlet and not reloading one of the pages that 
require a login, the session will timeout, and the user is now buried in 
one of the servlets, and I've lost the session/userprincipal.  It 
appears that interacting with a servlet that has no constraints does not 
reset the session timer.  Is that correct, or am I seeing it wrong?  I 
know the easy answer would be to add a constraint requiring login to 
access the servlet.  But with the current design, that's not going to 
work. Is there something I can do in the servlet and/or servlet config 
in web.xml to force servlet access to keep resetting the session timer 
so it won't expire without having to put role constraints directly on 
the servlet?


Just calling HttpServletRequest.getSession(false) from the Servlet 
should be sufficient.


Note you can monitor the expiration time for sessions using the Manager 
application. That might be helpful in testing.


Mark

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

PersistentManager and ClassNotFoundException

[Jakub Królikowski]

Hi,

I'm working with Tomcat 10.1.

When a user starts using the store in my web application, I save the
ShopCart object on the "cart" session attribute.
I want the "cart" attributes to return to the session after restarting the
app.


To enable session persistence I added



to the Context. It loads the StandardManager.

And this works fine - after reload / restart the object "ShopCart" is back
in the session.



I want to experiment with PersistentManager. Tomcat docs says: "
The persistence across restarts provided by the *StandardManager* is a
simpler implementation than that provided by the *PersistentManager*. If
robust, production quality persistence across restarts is required then the
*PersistentManager* should be used with an appropriate configuration.

"

I hope for a Listener of deserialization of the session attributes.

The new Manager configuration looks like this:







But it doesn't work. After restart I get this exception:


java.lang.ClassNotFoundException: ShopCart

at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1332)

at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1144)

at java.base/java.lang.Class.forName0(Native Method)

at java.base/java.lang.Class.forName(Class.java:534)

at java.base/java.lang.Class.forName(Class.java:513)

at
org.apache.catalina.util.CustomObjectInputStream.resolveClass(CustomObjectInputStream.java:158)

at
java.base/java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:2061)

at
java.base/java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1927)

at
java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2252)

at
java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1762)

at
java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:540)

at
java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:498)

at
org.apache.catalina.session.StandardSession.doReadObject(StandardSession.java:1198)

at
org.apache.catalina.session.StandardSession.readObjectData(StandardSession.java:831)

at org.apache.catalina.session.FileStore.load(FileStore.java:203)

at org.apache.catalina.session.StoreBase.processExpires(StoreBase.java:138)

at
org.apache.catalina.session.PersistentManagerBase.processExpires(PersistentManagerBase.java:409)

at
org.apache.catalina.session.ManagerBase.backgroundProcess(ManagerBase.java:587)

at
org.apache.catalina.core.StandardContext.backgroundProcess(StandardContext.java:4787)

at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1172)

at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1176)

at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1176)

at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1154)

at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)

at
java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:358)

at
java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)

at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)

at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)

at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:63)

at java.base/java.lang.Thread.run(Thread.java:1583)


I guess this means that the two managers use ClassLoader differently.
How to get the PersistentManager to work in this case?

Best regards,
--
Jakub Królikowski

Security Constraints and Session Timeout

[Jerry Malcolm]

I have some servlets that I can't put security constraints on at the 
web.xml level.  However, deep down in the code there are some places 
that I need a user to be logged in.  My overall UI ensures this all 
works by having certain JSPs with constraints that force the user to log 
in before getting to the servlet.  But if the user spends too much time 
interacting with the servlet and not reloading one of the pages that 
require a login, the session will timeout, and the user is now buried in 
one of the servlets, and I've lost the session/userprincipal.  It 
appears that interacting with a servlet that has no constraints does not 
reset the session timer.  Is that correct, or am I seeing it wrong?  I 
know the easy answer would be to add a constraint requiring login to 
access the servlet.  But with the current design, that's not going to 
work. Is there something I can do in the servlet and/or servlet config 
in web.xml to force servlet access to keep resetting the session timer 
so it won't expire without having to put role constraints directly on 
the servlet?


Thx

Jerry


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

RE: Re: Tomcat Console - 401 Unauthorized

[Garber, Frank]

And the winner is: Chuck 

I tried Chrome (instead of the Corporate mandated browser Edge) and I was right 
away challenged for credentials.

Thanks for all those who responded.


From: Chuck Caldarale 
Sent: Wednesday, May 22, 2024 4:36 PM
To: Tomcat Users List 
Subject: {EXTERNAL} Re: Tomcat Console - 401 Unauthorized

> On May 22, 2024, at 13: 31, Garber, Frank  com. INVALID> wrote: > > Not knowing how it’s supposed to behave, here’s 
> another clue. When I click on the “Server Status” button, I never get prompted




> On May 22, 2024, at 13:31, Garber, Frank 
> mailto:francis.gar...@elevancehealth.com.INVALID>>
>  wrote:

>

> Not knowing how it’s supposed to behave, here’s another clue. When I click on 
> the “Server Status” button, I never get prompted for credentials.





This sounds like a browser configuration problem. On the first attempt to 
access a protected resource, the server will return a 401 status with a 
WWW-Authenticate header listing the acceptable authentication mechanisms; for 
Tomcat, "Basic" is the default. The browser is then supposed to take the 
specified action to determine the credentials - for Basic, that’s the typical 
dialog box prompt.



If you’re using Edge (my condolences if so), go to edge://policy and look at 
the AuthSchemes entry; if it doesn’t include “basic”, you’ll never get the 
prompt.



Can you correct the Edge config or try a different browser?



  - Chuck



CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential
and privileged information or may otherwise be protected by law. Any
unauthorized review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail
and destroy all copies of the original message and any attachment thereto.

Re: Tomcat Console - 401 Unauthorized

[Chuck Caldarale]

> On May 22, 2024, at 13:31, Garber, Frank 
>  wrote:
> 
> Not knowing how it’s supposed to behave, here’s another clue. When I click on 
> the “Server Status” button, I never get prompted for credentials.


This sounds like a browser configuration problem. On the first attempt to 
access a protected resource, the server will return a 401 status with a 
WWW-Authenticate header listing the acceptable authentication mechanisms; for 
Tomcat, "Basic" is the default. The browser is then supposed to take the 
specified action to determine the credentials - for Basic, that’s the typical 
dialog box prompt.

If you’re using Edge (my condolences if so), go to edge://policy and look at 
the AuthSchemes entry; if it doesn’t include “basic”, you’ll never get the 
prompt.

Can you correct the Edge config or try a different browser?

  - Chuck

RE: Re: Tomcat Console - 401 Unauthorized

[Garber, Frank]

Not knowing how it’s supposed to behave, here’s another clue. When I click on 
the “Server Status” button, I never get prompted for credentials. Is it a 
permissions problem on the server itself. Like the server doesn’t have rights 
to the HTML pages?

Thanks in advance,

From: Garber, Frank
Sent: Wednesday, May 22, 2024 2:26 PM
To: Tomcat Users List 
Subject: RE: {EXTERNAL} Re: Tomcat Console - 401 Unauthorized

I’m not sure how the URLs got munged up.

What I have on my side is valid XML, so I’m not worried about that. I’m really 
just concerned that the following isn’t working:

  
  
  

   


Thanks in advance,

From: Chuck Caldarale mailto:n82...@gmail.com>>
Sent: Wednesday, May 22, 2024 2:16 PM
To: Tomcat Users List mailto:users@tomcat.apache.org>>
Subject: {EXTERNAL} Re: Tomcat Console - 401 Unauthorized

> On May 22, 2024, at 10: 51, Garber, Frank  com. INVALID> wrote: > > I've just installed Tomcat 9. 0. 89.  > 
> Tomcat runs, and I can get to the console at https: //urldefense. 
> com/v3/__http: //localhost: 
> 8080/__;!!IZ3lH8c!yts7ZdG2lLWkLHZXnQFxUeyJeHbX_NxqieI-zv0Ui8nBlMzfnQ_mbT_M5evoEof6o-OZ5azA1nAyFvzyQAcQ$




> On May 22, 2024, at 10:51, Garber, Frank 
> mailto:francis.gar...@elevancehealth.com.INVALID>>
>  wrote:

>

> I've just installed Tomcat 9.0.89.











> Tomcat runs, and I can get to the console at 
> https://urldefense.com/v3/__http://localhost:8080/__;!!IZ3lH8c!yts7ZdG2lLWkLHZXnQFxUeyJeHbX_NxqieI-zv0Ui8nBlMzfnQ_mbT_M5evoEof6o-OZ5azA1nAyFvzyQAcQ$
>  but, when I click on "Server Status" I get the 401 Unauthorized page.











> I've been editing the conf\tomcat-users.xml file and have tried MANY 
> different combinations of entries but, can't get past the 401 problem.











> Here's my current file contents:

>

> 

>

>  xmlns=https://urldefense.com/v3/__http://tomcat.apache.org/xml__;!!IZ3lH8c!yts7ZdG2lLWkLHZXnQFxUeyJeHbX_NxqieI-zv0Ui8nBlMzfnQ_mbT_M5evoEof6o-OZ5azA1nAyFqswncMY$

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

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

>  version="1.0">





If the above is what you actually have in the .xml file, you should also be 
seeing parsing errors in the catalina.out log file, since it’s not valid XML. 
Once corrected to the following, access to the server status pages worked 
properly.



https://urldefense.com/v3/__http://tomcat.apache.org/xml__;!!IZ3lH8c!yts7ZdG2lLWkLHZXnQFxUeyJeHbX_NxqieI-zv0Ui8nBlMzfnQ_mbT_M5evoEof6o-OZ5azA1nAyFqswncMY$"

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

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

  version="1.0">



Note the missing quotes and seriously munged-up xsi:schemaLocation attribute in 
your posting.



If you’re using an editor that thinks it’s clever to convert http:// references 
into HTML, get a better editor.



  - Chuck



CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential
and privileged information or may otherwise be protected by law. Any
unauthorized review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail
and destroy all copies of the original message and any attachment thereto.

RE: Re: Tomcat Console - 401 Unauthorized

[Garber, Frank]

I’m not sure how the URLs got munged up.

What I have on my side is valid XML, so I’m not worried about that. I’m really 
just concerned that the following isn’t working:

  
  
  

   


Thanks in advance,

From: Chuck Caldarale 
Sent: Wednesday, May 22, 2024 2:16 PM
To: Tomcat Users List 
Subject: {EXTERNAL} Re: Tomcat Console - 401 Unauthorized

> On May 22, 2024, at 10: 51, Garber, Frank  com. INVALID> wrote: > > I've just installed Tomcat 9. 0. 89.  > 
> Tomcat runs, and I can get to the console at https: //urldefense. 
> com/v3/__http: //localhost: 
> 8080/__;!!IZ3lH8c!yts7ZdG2lLWkLHZXnQFxUeyJeHbX_NxqieI-zv0Ui8nBlMzfnQ_mbT_M5evoEof6o-OZ5azA1nAyFvzyQAcQ$




> On May 22, 2024, at 10:51, Garber, Frank 
> mailto:francis.gar...@elevancehealth.com.INVALID>>
>  wrote:

>

> I've just installed Tomcat 9.0.89.











> Tomcat runs, and I can get to the console at 
> https://urldefense.com/v3/__http://localhost:8080/__;!!IZ3lH8c!yts7ZdG2lLWkLHZXnQFxUeyJeHbX_NxqieI-zv0Ui8nBlMzfnQ_mbT_M5evoEof6o-OZ5azA1nAyFvzyQAcQ$
>  but, when I click on "Server Status" I get the 401 Unauthorized page.











> I've been editing the conf\tomcat-users.xml file and have tried MANY 
> different combinations of entries but, can't get past the 401 problem.











> Here's my current file contents:

>

> 

>

>  xmlns=https://urldefense.com/v3/__http://tomcat.apache.org/xml__;!!IZ3lH8c!yts7ZdG2lLWkLHZXnQFxUeyJeHbX_NxqieI-zv0Ui8nBlMzfnQ_mbT_M5evoEof6o-OZ5azA1nAyFqswncMY$

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

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

>  version="1.0">





If the above is what you actually have in the .xml file, you should also be 
seeing parsing errors in the catalina.out log file, since it’s not valid XML. 
Once corrected to the following, access to the server status pages worked 
properly.



https://urldefense.com/v3/__http://tomcat.apache.org/xml__;!!IZ3lH8c!yts7ZdG2lLWkLHZXnQFxUeyJeHbX_NxqieI-zv0Ui8nBlMzfnQ_mbT_M5evoEof6o-OZ5azA1nAyFqswncMY$"

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

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

  version="1.0">



Note the missing quotes and seriously munged-up xsi:schemaLocation attribute in 
your posting.



If you’re using an editor that thinks it’s clever to convert http:// references 
into HTML, get a better editor.



  - Chuck



CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential
and privileged information or may otherwise be protected by law. Any
unauthorized review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail
and destroy all copies of the original message and any attachment thereto.

Re: Tomcat Console - 401 Unauthorized

[Chuck Caldarale]

> On May 22, 2024, at 10:51, Garber, Frank 
>  wrote:
> 
> I've just installed Tomcat 9.0.89.





> Tomcat runs, and I can get to the console at http://localhost:8080/ but, when 
> I click on "Server Status" I get the 401 Unauthorized page.





> I've been editing the conf\tomcat-users.xml file and have tried MANY 
> different combinations of entries but, can't get past the 401 problem.





> Here's my current file contents:
> 
> 
> 
> http://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">


If the above is what you actually have in the .xml file, you should also be 
seeing parsing errors in the catalina.out log file, since it’s not valid XML. 
Once corrected to the following, access to the server status pages worked 
properly.

http://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">

Note the missing quotes and seriously munged-up xsi:schemaLocation attribute in 
your posting.

If you’re using an editor that thinks it’s clever to convert http:// references 
into HTML, get a better editor.

  - Chuck

Tomcat Console - 401 Unauthorized

[Garber, Frank]

Hello Group,

I've just installed Tomcat 9.0.89.

First a the first few lines on the Catalina log:
NOTE: Picked up JDK_JAVA_OPTIONS:  --add-opens=java.base/java.lang=ALL-UNNAMED 
--add-opens=java.base/java.io=ALL-UNNAMED 
--add-opens=java.base/java.util=ALL-UNNAMED 
--add-opens=java.base/java.util.concurrent=ALL-UNNAMED 
--add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
usage: java org.apache.catalina.startup.Catalina [ -config {pathname} ] [ 
-nonaming ] [ -generateCode [ {pathname} ] ] [ -useGeneratedCode ] { -help | 
start | stop }
22-May-2024 11:16:47.794 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Server version name:   
Apache Tomcat/9.0.89

Tomcat runs, and I can get to the console at http://localhost:8080/ but, when I 
click on "Server Status" I get the 401 Unauthorized page.

I've been editing the conf\tomcat-users.xml file and have tried MANY different 
combinations of entries but, can't get past the 401 problem. I know editing the 
correct file as I see Tomcat logging:
22-May-2024 11:30:00.479 INFO [Catalina-utility-1] 
org.apache.catalina.users.MemoryUserDatabase.backgroundProcess Reloading memory 
user database [UserDatabase] from updated source 
[file:/C:/myProgs/apache-tomcat-9.0.89/conf/tomcat-users.xml]

Regardless, I stop and restart Tomcat to make sure it's picking up the changes.

Here's my current file contents:



http://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">

  
  

   




Thanks in advance,
F

CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential
and privileged information or may otherwise be protected by law. Any
unauthorized review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail
and destroy all copies of the original message and any attachment thereto.

Re: Regarding Tomcat url redirection

[lavanya tech]

Hello Chris,
Separate server.xml files means that you have to have two separate
Tomcat processes.
 --> ofcourse, we defined two seperate processes for it but still there was
some bug with Tomcat as the webpage is fluctuatiting.

The best fix is to deploy the two applications normally without any
funny business. Put both applications into webapps/ with no 
elements in server.xml and let them deploy. Use the correct URLs to
access them. It's obviously some internal thing to your company because
nobody is going to use :8443 in the real world.
- Definitely, its an internal thing and thats the reason I have posted here
for suggestions and I always tried the things that were suggested by you.
I'm sorry, but it seems like you are being given arbitrary and weird
requirements almost as a game
- I have not given requirements as a game, please understand that those are
the requirements that one needed to achieve with tomcat.I understood with
Tomcat its getting complicated and hence solved it by installing an reverse
proxy where my requirements are fulfilled.

Thanks for your support.

Thanks,
Lavanya


On Thu, May 16, 2024 at 11:52 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Lavanya,
>
> On 5/15/24 09:09, lavanya tech wrote:
> > Hi Chris,
> >
> >> 
> >
> > If i remove this from server.xml file i have the below error.
> >
> > Message java.lang.NoClassDefFoundError: org/towl/indexer/web/Prefix
> >
> > Description The server encountered an unexpected condition that prevented
> > it from fulfilling the request.
> >
> > Exception
> >
> > jakarta.servlet.ServletException: java.lang.NoClassDefFoundError:
> > org/towl/indexer/web/Prefix
> > org.apache.jasper.servlet.JspServlet.service(JspServlet.java:333)
> > jakarta.servlet.http.HttpServlet.service(HttpServlet.java:658)
> > org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51)
>
> That smells like a CLASSPATH problem where your application is not
> actually packaged properly. It could be something else, but it looks
> suspicious.
>
> > The "aliasing" will always be weird. IMO it's better to redirect. If you
> > change to redirect, does everything *work*, even if you don't like how
> > the browser's URL bar displays?
> >--> I tried but it didnot work
> > ok apart from this tpic , we have one more issue found.
> >
> >
> > Actually application team, they are deploying two applications one with
> > towl (which you are already aware) the other one is (towl-app) they have
> > defined seperate server.xml for both.
>
> Separate server.xml files means that you have to have two separate
> Tomcat processes.
>
> > Name:server.lbg.com
> > Address:  192.168.200.120
> > Aliases:  example.lbg.com
> >
> >
> > Name:server.lbg.com
> > Address:  192.168.200.120
> > Aliases:  example-app.lbg.com
> >
> > which means we have two aliases for server.lbg.com , earlier we were
> > concentrating only on one example.lbg.com , now i wanted to somehow
> enable
> > access as the same for the other one also
> > https://example-app.lbg.com --> https://server.lbg.com:8444/towl-app
> >
> > So i created iptable rule in the sameway as before redirect 443 to 8444
> and
> > i have the urls working same as example.lbg.com
> >
> > Both the server.xml files are here
> >
> > /git/towl/apachetomcat/conf/server.xml
> > /git/towl-app/apachetomcat/conf/server.xml --> I changed the port of
> > connectors and everything
> >
> > But now when i try to access https://example.lbg.com --> I get webpage
> of
> > https://example-app.lbg.com and sometimes i get webpage of
> > https://example.lbg.com after refresh itself which is wierd
> >
> > May i know why this is happening. If we fix this then I am thinking to
> > disable the unwated urls leaving the required ones. for example the below
> > ones. I think that would be easier ? rather than redirecting or
> aliasing-->
> > Because we noticed that towl application is already pointing with
> > https://example.lbg.com
> >
> > https://server.lbg.com:8443
> >https://example-lbg.com:8443
> >
> > 
> > https://server.lbg.com:8444
> >https://example-lbg.com:8444
> >
> > 
> >
> > kindly suggest us a fix.
>
> The best fix is to deploy the two applications normally without any
> funny business. Put both applications into webapps/ with no 
> elements in server.xml and let them deploy. Use the correct URLs to
> access them. It's obviously some internal thing to your company because
> nobody is going to use :8443 in the real world.
>
> I'm sorry, but it seems like you are being given arbitrary and weird
> requirements almost as a game.
>
> I'm not sure I can help you any further at this point.
>
> -chris
>
> > On Wed, May 15, 2024 at 2:16 PM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> >> Lavanya,
> >>
> >> On 5/15/24 04:43, lavanya 

Re: JVM crashing with caCertificatePath in server.xml

[Michael Osipov]

On 2024/05/22 00:05:18 Andy Arismendi wrote:
> Hi Micheal, you had asked to try these - 
> http://home.apache.org/~michaelo/issues/tomcat/openssl-crash/. I replaced my 
> files with these but Tomcat failed to start at this point with this message -
> 
> 22-May-2024 00:02:30.808 INFO [main] org.apache.coyote.AbstractProtocol.init 
> Initializing ProtocolHandler ["https-openssl-nio2-10.232.115.117-443"]
> OPENSSL_Uplink(7FFEEBF10C88,08): no OPENSSL_Applink

Copied and compiled applnk.c into the library, and updated at the given 
location. Please try again.

M

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

Re: JVM crashing with caCertificatePath in server.xml

[Andy Arismendi]

Michael, good news, it’s working now. Issue was on my end, was using a custom 
OpenSSL installer that was built with FIPS and it had also put the two openssl 
lib DLLs in Window System32, after fixing that Tomcat started without JVM crash 
with caCertificatePath set in server.xml.

Thanks!
-Andy

Re: JVM crashing with caCertificatePath in server.xml

[Michael Osipov]

On 2024/05/22 00:05:18 Andy Arismendi wrote:
> Hi Micheal, you had asked to try these - 
> http://home.apache.org/~michaelo/issues/tomcat/openssl-crash/. I replaced my 
> files with these but Tomcat failed to start at this point with this message -
> 
> 22-May-2024 00:02:30.808 INFO [main] org.apache.coyote.AbstractProtocol.init 
> Initializing ProtocolHandler ["https-openssl-nio2-10.232.115.117-443"]
> OPENSSL_Uplink(7FFEEBF10C88,08): no OPENSSL_Applink

Darn, the dreaded applink.c. Though, I do not understand why it works for me, 
but not for you. I need to see how to add the object into tcnative's build. 
Give me some time.

M

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

Re: JVM crashing with caCertificatePath in server.xml

[Michael Osipov]

On 2024/05/21 18:04:18 Christopher Schultz wrote:
> Michael,
> 
> On 5/21/24 03:32, Michael Osipov wrote:
> > On 2024/05/20 13:30:43 Christopher Schultz wrote:
> >> Michael,
> >>
> >> On 5/20/24 06:52, Michael Osipov wrote:
> >>> On 2024/05/17 15:11:58 Christopher Schultz wrote:
>  Michael,
> 
>  On 5/17/24 03:42, Michael Osipov wrote:
> > On 2024/05/16 21:37:34 Christopher Schultz wrote:
> >> Michael,
> >>
> >> On 5/16/24 12:00, Michael Osipov wrote:
> >>> On 2024/05/16 15:55:04 Andy Arismendi wrote:
>  Ok great! Thank you for taking the time and making the effort to 
>  look into this Michael, much appreciated!
> >>>
> >>> Here is a dynamically linked, patched version until there is an 
> >>> official release: 
> >>> http://home.apache.org/~michaelo/issues/tomcat/openssl-crash/
> >>>
> >>> Please give it a try.
> >>
> >> Since you have produced a debug build of tcnative (and other
> >> components?) could you post the debug trace of the native stack?
> >
> > Unfortunately I can't. While I have the files with debug symbols I am 
> > limited by https://github.com/mturk/cmsc?tab=readme-ov-file#warning. I 
> > don't have a full blown Visual Studio installed.
> 
>  Okay. If you did build with VS, can you get a debug build with a 
>  backtrace?
> >>>
> >>> Unfortunately not. Currently, I don't have the capacity to do so.
> >>>
>  I guess you already tracked the crash to openssl_fopen. When I did a
>  decompile of the official binary, I can see the code but it's very
>  difficult to read:
> 
>  void FUN_1800cccd0(char *param_1,char *param_2)
> 
>  {
>  
>  }
> 
>  Thanks for helping to at least link it to this openssl source:
> 
>  https://github.com/openssl/openssl/blob/45f5d51b72a262bf85c4461fbded91485ce6b9da/crypto/o_fopen.c#L38
> 
>  Since libtcnative.dll is statically-linked, it doesn't even need a
>  symbol table for internal calls so the openssl_fopen token is completely
>  lost. Also, libtcnative contains all of TCN, APR, and OpenSSL. TCN
>  doesn't make direct Win32 calls so that leaves ... all of APR and
>  OpenSSL to search for this pattern of calls.
> 
>  Since you know where the fault is occurring, do you know the native
>  call-trace being performed? I'd love to know which component along the
>  way is not properly checking for NULL.
> >>>
> >>> Yes, sure:
> >>> * 
> >>> https://github.com/apache/tomcat-native/blob/6a6a6b2395036c6a6cabb2b8af22aa329e438436/native/src/sslcontext.c#L711
> >>
> >> So, 'file' is null on this line? If so, I guess the bug is in tcnative.
> > 
> > Yes, it is NULL. I don't think that the bug in necessarily in tcnative 
> > because othe functions in OpenSSL do support NULL and fail appropriately. I 
> > consider this either bad documenation or missing input validation.
> > 
> >>> * 
> >>> https://github.com/openssl/openssl/blob/45f5d51b72a262bf85c4461fbded91485ce6b9da/ssl/ssl_cert.c#L834
> >>> * 
> >>> https://github.com/openssl/openssl/blob/45f5d51b72a262bf85c4461fbded91485ce6b9da/crypto/o_fopen.c#L42
> >>
> >> Where does the call go from BIO_read_filename to openssl_fopen?
> > 
> > Here: 
> > https://github.com/openssl/openssl/blob/45f5d51b72a262bf85c4461fbded91485ce6b9da/crypto/bio/bss_file.c#L267-L295
> 
> That's in file_ctrl(). What's the full call trace from tcnative's 
> setCACertificate through to openssl_fopen?

BIO_read_filename() is a macro, if you trace down the resolution manually you 
will end up in the resources I have provided you. Took me some time.

M

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

Re: JVM crashing with caCertificatePath in server.xml

[Andy Arismendi]

Hi Micheal, you had asked to try these - 
http://home.apache.org/~michaelo/issues/tomcat/openssl-crash/. I replaced my 
files with these but Tomcat failed to start at this point with this message -

22-May-2024 00:02:30.808 INFO [main] org.apache.coyote.AbstractProtocol.init 
Initializing ProtocolHandler ["https-openssl-nio2-10.232.115.117-443"]
OPENSSL_Uplink(7FFEEBF10C88,08): no OPENSSL_Applink

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

Re: JVM crashing with caCertificatePath in server.xml

[Christopher Schultz]

Michael,

On 5/21/24 03:32, Michael Osipov wrote:

On 2024/05/20 13:30:43 Christopher Schultz wrote:

Michael,

On 5/20/24 06:52, Michael Osipov wrote:

On 2024/05/17 15:11:58 Christopher Schultz wrote:

Michael,

On 5/17/24 03:42, Michael Osipov wrote:

On 2024/05/16 21:37:34 Christopher Schultz wrote:

Michael,

On 5/16/24 12:00, Michael Osipov wrote:

On 2024/05/16 15:55:04 Andy Arismendi wrote:

Ok great! Thank you for taking the time and making the effort to look into this 
Michael, much appreciated!


Here is a dynamically linked, patched version until there is an official 
release: http://home.apache.org/~michaelo/issues/tomcat/openssl-crash/

Please give it a try.


Since you have produced a debug build of tcnative (and other
components?) could you post the debug trace of the native stack?


Unfortunately I can't. While I have the files with debug symbols I am limited 
by https://github.com/mturk/cmsc?tab=readme-ov-file#warning. I don't have a 
full blown Visual Studio installed.


Okay. If you did build with VS, can you get a debug build with a backtrace?


Unfortunately not. Currently, I don't have the capacity to do so.


I guess you already tracked the crash to openssl_fopen. When I did a
decompile of the official binary, I can see the code but it's very
difficult to read:

void FUN_1800cccd0(char *param_1,char *param_2)

{



}

Thanks for helping to at least link it to this openssl source:

https://github.com/openssl/openssl/blob/45f5d51b72a262bf85c4461fbded91485ce6b9da/crypto/o_fopen.c#L38

Since libtcnative.dll is statically-linked, it doesn't even need a
symbol table for internal calls so the openssl_fopen token is completely
lost. Also, libtcnative contains all of TCN, APR, and OpenSSL. TCN
doesn't make direct Win32 calls so that leaves ... all of APR and
OpenSSL to search for this pattern of calls.

Since you know where the fault is occurring, do you know the native
call-trace being performed? I'd love to know which component along the
way is not properly checking for NULL.


Yes, sure:
* 
https://github.com/apache/tomcat-native/blob/6a6a6b2395036c6a6cabb2b8af22aa329e438436/native/src/sslcontext.c#L711


So, 'file' is null on this line? If so, I guess the bug is in tcnative.


Yes, it is NULL. I don't think that the bug in necessarily in tcnative because 
othe functions in OpenSSL do support NULL and fail appropriately. I consider 
this either bad documenation or missing input validation.


* 
https://github.com/openssl/openssl/blob/45f5d51b72a262bf85c4461fbded91485ce6b9da/ssl/ssl_cert.c#L834
* 
https://github.com/openssl/openssl/blob/45f5d51b72a262bf85c4461fbded91485ce6b9da/crypto/o_fopen.c#L42


Where does the call go from BIO_read_filename to openssl_fopen?


Here: 
https://github.com/openssl/openssl/blob/45f5d51b72a262bf85c4461fbded91485ce6b9da/crypto/bio/bss_file.c#L267-L295


That's in file_ctrl(). What's the full call trace from tcnative's 
setCACertificate through to openssl_fopen?



The NULL pointer gets passed around and strlen() chokes on it.

Please also read my upstream report: 
https://github.com/openssl/openssl/issues/24416


Yes, I'm getting ready to post to that and wanted more information,
since it doesn't look like the OpenSSL team cares about the report.


Yes, please.


-chris


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

Re: Win10 installation progress

[Christopher Schultz]

Hello,

On 5/18/24 23:40, DdC wrote:

Gave up on installing 9.0.88. on Win10.


Why did you give up? ZIP installation is a single command (either via 
CMD or UI shell). EXE installer is pretty straightforward, too. There's 
also a third-party installer that has a few more features including the 
ability to upgrade an existing installation. (I recommend against 
upgrading an existing installation specifically, but that's not a 
recommendation against that third-party installer.)


Do you mean you gave up trying to get your application running on it?


Succeeded with  10.1.23 andjdk-18.0.2.1.


Why Java 18? It's been EOL for years at this point. You should use Java 
21 these days for anything new.


Did you know that Tomcat 10 is fundamentally different than previous 
versions?



The lib directory has j2ee.jar, which I have used in earliertomcat versions.


What does j2ee.jar contain? That seems so unspecific as to be problematic.


Compilation of a system was OK apart from some warnings because Java
has changed since the code was written.

?


There is a web.xml file in WEB-INF.


Okay...


Invoking a servlet gives a 500 error with the ominous complaint:
class su.SUlogin cannot be cast to jakarta.servlet.Servlet
(su.SUlogin is in unnamed module of loader org.apache.catalina...
) Looks like that my code is quite out of date.Any suggestion for a
fix?Going back to an earlier tomcat?

Did you read the migration guide for Tomcat 10.1?

I would highly recommend going back to 9.0 for the time being. If you 
remove j2ee.jar, does your project compile? If not, what errors do you 
get (missing classes, of course, but what major packages are missing)?


j2ee.jar sounds like an uber-jar with "everything we need in it" without 
any specificity. You should replace that with modern, separate libraries 
that support your application.


-chris

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

Re: JVM crashing with caCertificatePath in server.xml

[Rémy Maucherat]

On Tue, May 21, 2024 at 9:33 AM Michael Osipov  wrote:
>
> On 2024/05/20 13:30:43 Christopher Schultz wrote:
> > Michael,
> >
> > On 5/20/24 06:52, Michael Osipov wrote:
> > > On 2024/05/17 15:11:58 Christopher Schultz wrote:
> > >> Michael,
> > >>
> > >> On 5/17/24 03:42, Michael Osipov wrote:
> > >>> On 2024/05/16 21:37:34 Christopher Schultz wrote:
> >  Michael,
> > 
> >  On 5/16/24 12:00, Michael Osipov wrote:
> > > On 2024/05/16 15:55:04 Andy Arismendi wrote:
> > >> Ok great! Thank you for taking the time and making the effort to 
> > >> look into this Michael, much appreciated!
> > >
> > > Here is a dynamically linked, patched version until there is an 
> > > official release: 
> > > http://home.apache.org/~michaelo/issues/tomcat/openssl-crash/
> > >
> > > Please give it a try.
> > 
> >  Since you have produced a debug build of tcnative (and other
> >  components?) could you post the debug trace of the native stack?
> > >>>
> > >>> Unfortunately I can't. While I have the files with debug symbols I am 
> > >>> limited by https://github.com/mturk/cmsc?tab=readme-ov-file#warning. I 
> > >>> don't have a full blown Visual Studio installed.
> > >>
> > >> Okay. If you did build with VS, can you get a debug build with a 
> > >> backtrace?
> > >
> > > Unfortunately not. Currently, I don't have the capacity to do so.
> > >
> > >> I guess you already tracked the crash to openssl_fopen. When I did a
> > >> decompile of the official binary, I can see the code but it's very
> > >> difficult to read:
> > >>
> > >> void FUN_1800cccd0(char *param_1,char *param_2)
> > >>
> > >> {
> > >> char cVar1;
> > >> longlong lVar2;
> > >> int iVar3;
> > >> DWORD DVar4;
> > >> char *pcVar5;
> > >> FILE *pFVar6;
> > >> int *piVar7;
> > >> ulonglong uVar8;
> > >> uint uVar9;
> > >> int cbMultiByte;
> > >> undefined *puVar10;
> > >> undefined *puVar11;
> > >> uint uVar12;
> > >> undefined8 uStackY_80;
> > >> undefined auStackY_78 [32];
> > >> wchar_t local_48 [8];
> > >> ulonglong local_38;
> > >> undefined8 uStack_30;
> > >>
> > >> uStack_30 = 0x1800ccce3;
> > >> local_38 = DAT_18033f868 ^ (ulonglong)local_48;
> > >> cVar1 = *param_1;
> > >> uVar12 = 0;
> > >> pcVar5 = param_1;
> > >> for (uVar9 = uVar12; (cVar1 != '\0' && (uVar9 < 0x8000)); uVar9 =
> > >> uVar9 + 1) {
> > >>   pcVar5 = pcVar5 + 1;
> > >>   cVar1 = *pcVar5;
> > >> }
> > >> cbMultiByte = (uVar9 & 0x7fff) + 1;
> > >> uStackY_80 = 0x1800ccd50;
> > >> iVar3 = 
> > >> MultiByteToWideChar(0xfde9,8,param_1,cbMultiByte,(LPWSTR)0x0,0);
> > >> DVar4 = 8;
> > >> if (iVar3 < 1) {
> > >>   uStackY_80 = 0x1800ccd5d;
> > >>   DVar4 = GetLastError();
> > >>   if (DVar4 == 0x3ec) {
> > >> uStackY_80 = 0x1800ccd84;
> > >> iVar3 =
> > >> MultiByteToWideChar(0xfde9,0,param_1,cbMultiByte,(LPWSTR)0x0,0);
> > >> DVar4 = 0;
> > >> if (0 < iVar3) goto LAB_1800ccdac;
> > >>   }
> > >>   uStackY_80 = 0x1800ccd91;
> > >>   DVar4 = GetLastError();
> > >>   puVar10 = auStackY_78;
> > >>   puVar11 = auStackY_78;
> > >>   if (DVar4 != 0x459) goto LAB_1800cce89;
> > >> }
> > >> else {
> > >> LAB_1800ccdac:
> > >>   uVar8 = (longlong)iVar3 * 2 + 0xf;
> > >>   if (uVar8 <= (ulonglong)((longlong)iVar3 * 2)) {
> > >> uVar8 = 0xff0;
> > >>   }
> > >>   uStackY_80 = 0x1800ccdd1;
> > >>   lVar2 = -(uVar8 & 0xfff0);
> > >>   *(int *)( + lVar2) = iVar3;
> > >>   *(wchar_t **)( + lVar2) = (wchar_t
> > >> *)((longlong)local_48 + lVar2);
> > >>   *(undefined8 *)(auStackY_78 + lVar2 + -8) = 0x1800ccdf7;
> > >>   iVar3 = MultiByteToWideChar(0xfde9,DVar4,param_1,cbMultiByte,
> > >>   *(LPWSTR *)( +
> > >> lVar2),
> > >>   *(int *)( +
> > >> lVar2));
> > >>   puVar11 = auStackY_78 + lVar2;
> > >>   if (iVar3 == 0) goto LAB_1800cce89;
> > >>   cVar1 = *param_2;
> > >>   pcVar5 = param_2;
> > >>   for (; (cVar1 != '\0' && (uVar12 < 0x8000)); uVar12 = uVar12 + 
> > >> 1) {
> > >> pcVar5 = pcVar5 + 1;
> > >> cVar1 = *pcVar5;
> > >>   }
> > >>   *(undefined4 *)( + lVar2) = 8;
> > >>   *(wchar_t **)( + lVar2) = local_48;
> > >>   *(undefined8 *)(auStackY_78 + lVar2 + -8) = 0x1800cce4d;
> > >>   iVar3 = MultiByteToWideChar(0xfde9,0,param_2,(uVar12 & 0x7fff) 
> > >> + 1,
> > >>   *(LPWSTR *)( +
> > >> lVar2),
> > >>   *(int *)( +
> > >> lVar2));
> > >>   puVar11 = auStackY_78 + lVar2;
> > >>   if (iVar3 == 0) goto LAB_1800cce89;
> > >>   *(undefined8 *)(auStackY_78 + lVar2 + -8) = 0x1800cce5d;
> > >>   pFVar6 = _wfopen((wchar_t *)((longlong)local_48 + lVar2),local_48);
> > >>   

Re: JVM crashing with caCertificatePath in server.xml

[Michael Osipov]

On 2024/05/20 13:30:43 Christopher Schultz wrote:
> Michael,
> 
> On 5/20/24 06:52, Michael Osipov wrote:
> > On 2024/05/17 15:11:58 Christopher Schultz wrote:
> >> Michael,
> >>
> >> On 5/17/24 03:42, Michael Osipov wrote:
> >>> On 2024/05/16 21:37:34 Christopher Schultz wrote:
>  Michael,
> 
>  On 5/16/24 12:00, Michael Osipov wrote:
> > On 2024/05/16 15:55:04 Andy Arismendi wrote:
> >> Ok great! Thank you for taking the time and making the effort to look 
> >> into this Michael, much appreciated!
> >
> > Here is a dynamically linked, patched version until there is an 
> > official release: 
> > http://home.apache.org/~michaelo/issues/tomcat/openssl-crash/
> >
> > Please give it a try.
> 
>  Since you have produced a debug build of tcnative (and other
>  components?) could you post the debug trace of the native stack?
> >>>
> >>> Unfortunately I can't. While I have the files with debug symbols I am 
> >>> limited by https://github.com/mturk/cmsc?tab=readme-ov-file#warning. I 
> >>> don't have a full blown Visual Studio installed.
> >>
> >> Okay. If you did build with VS, can you get a debug build with a backtrace?
> > 
> > Unfortunately not. Currently, I don't have the capacity to do so.
> > 
> >> I guess you already tracked the crash to openssl_fopen. When I did a
> >> decompile of the official binary, I can see the code but it's very
> >> difficult to read:
> >>
> >> void FUN_1800cccd0(char *param_1,char *param_2)
> >>
> >> {
> >> char cVar1;
> >> longlong lVar2;
> >> int iVar3;
> >> DWORD DVar4;
> >> char *pcVar5;
> >> FILE *pFVar6;
> >> int *piVar7;
> >> ulonglong uVar8;
> >> uint uVar9;
> >> int cbMultiByte;
> >> undefined *puVar10;
> >> undefined *puVar11;
> >> uint uVar12;
> >> undefined8 uStackY_80;
> >> undefined auStackY_78 [32];
> >> wchar_t local_48 [8];
> >> ulonglong local_38;
> >> undefined8 uStack_30;
> >>
> >> uStack_30 = 0x1800ccce3;
> >> local_38 = DAT_18033f868 ^ (ulonglong)local_48;
> >> cVar1 = *param_1;
> >> uVar12 = 0;
> >> pcVar5 = param_1;
> >> for (uVar9 = uVar12; (cVar1 != '\0' && (uVar9 < 0x8000)); uVar9 =
> >> uVar9 + 1) {
> >>   pcVar5 = pcVar5 + 1;
> >>   cVar1 = *pcVar5;
> >> }
> >> cbMultiByte = (uVar9 & 0x7fff) + 1;
> >> uStackY_80 = 0x1800ccd50;
> >> iVar3 = 
> >> MultiByteToWideChar(0xfde9,8,param_1,cbMultiByte,(LPWSTR)0x0,0);
> >> DVar4 = 8;
> >> if (iVar3 < 1) {
> >>   uStackY_80 = 0x1800ccd5d;
> >>   DVar4 = GetLastError();
> >>   if (DVar4 == 0x3ec) {
> >> uStackY_80 = 0x1800ccd84;
> >> iVar3 =
> >> MultiByteToWideChar(0xfde9,0,param_1,cbMultiByte,(LPWSTR)0x0,0);
> >> DVar4 = 0;
> >> if (0 < iVar3) goto LAB_1800ccdac;
> >>   }
> >>   uStackY_80 = 0x1800ccd91;
> >>   DVar4 = GetLastError();
> >>   puVar10 = auStackY_78;
> >>   puVar11 = auStackY_78;
> >>   if (DVar4 != 0x459) goto LAB_1800cce89;
> >> }
> >> else {
> >> LAB_1800ccdac:
> >>   uVar8 = (longlong)iVar3 * 2 + 0xf;
> >>   if (uVar8 <= (ulonglong)((longlong)iVar3 * 2)) {
> >> uVar8 = 0xff0;
> >>   }
> >>   uStackY_80 = 0x1800ccdd1;
> >>   lVar2 = -(uVar8 & 0xfff0);
> >>   *(int *)( + lVar2) = iVar3;
> >>   *(wchar_t **)( + lVar2) = (wchar_t
> >> *)((longlong)local_48 + lVar2);
> >>   *(undefined8 *)(auStackY_78 + lVar2 + -8) = 0x1800ccdf7;
> >>   iVar3 = MultiByteToWideChar(0xfde9,DVar4,param_1,cbMultiByte,
> >>   *(LPWSTR *)( +
> >> lVar2),
> >>   *(int *)( +
> >> lVar2));
> >>   puVar11 = auStackY_78 + lVar2;
> >>   if (iVar3 == 0) goto LAB_1800cce89;
> >>   cVar1 = *param_2;
> >>   pcVar5 = param_2;
> >>   for (; (cVar1 != '\0' && (uVar12 < 0x8000)); uVar12 = uVar12 + 
> >> 1) {
> >> pcVar5 = pcVar5 + 1;
> >> cVar1 = *pcVar5;
> >>   }
> >>   *(undefined4 *)( + lVar2) = 8;
> >>   *(wchar_t **)( + lVar2) = local_48;
> >>   *(undefined8 *)(auStackY_78 + lVar2 + -8) = 0x1800cce4d;
> >>   iVar3 = MultiByteToWideChar(0xfde9,0,param_2,(uVar12 & 0x7fff) + 
> >> 1,
> >>   *(LPWSTR *)( +
> >> lVar2),
> >>   *(int *)( +
> >> lVar2));
> >>   puVar11 = auStackY_78 + lVar2;
> >>   if (iVar3 == 0) goto LAB_1800cce89;
> >>   *(undefined8 *)(auStackY_78 + lVar2 + -8) = 0x1800cce5d;
> >>   pFVar6 = _wfopen((wchar_t *)((longlong)local_48 + lVar2),local_48);
> >>   puVar11 = auStackY_78 + lVar2;
> >>   if (pFVar6 != (FILE *)0x0) goto LAB_1800cce89;
> >>   *(undefined8 *)(auStackY_78 + lVar2 + -8) = 0x1800cce6a;
> >>   piVar7 = _errno();
> >>   puVar10 = auStackY_78 + lVar2;
> >>   if (*piVar7 != 2) {
> >> *(undefined8 *)(auStackY_78 + lVar2 + -8) = 

Re: JVM crashing with caCertificatePath in server.xml

[Christopher Schultz]

Michael,

On 5/20/24 06:52, Michael Osipov wrote:

On 2024/05/17 15:11:58 Christopher Schultz wrote:

Michael,

On 5/17/24 03:42, Michael Osipov wrote:

On 2024/05/16 21:37:34 Christopher Schultz wrote:

Michael,

On 5/16/24 12:00, Michael Osipov wrote:

On 2024/05/16 15:55:04 Andy Arismendi wrote:

Ok great! Thank you for taking the time and making the effort to look into this 
Michael, much appreciated!


Here is a dynamically linked, patched version until there is an official 
release: http://home.apache.org/~michaelo/issues/tomcat/openssl-crash/

Please give it a try.


Since you have produced a debug build of tcnative (and other
components?) could you post the debug trace of the native stack?


Unfortunately I can't. While I have the files with debug symbols I am limited 
by https://github.com/mturk/cmsc?tab=readme-ov-file#warning. I don't have a 
full blown Visual Studio installed.


Okay. If you did build with VS, can you get a debug build with a backtrace?


Unfortunately not. Currently, I don't have the capacity to do so.


I guess you already tracked the crash to openssl_fopen. When I did a
decompile of the official binary, I can see the code but it's very
difficult to read:

void FUN_1800cccd0(char *param_1,char *param_2)

{
char cVar1;
longlong lVar2;
int iVar3;
DWORD DVar4;
char *pcVar5;
FILE *pFVar6;
int *piVar7;
ulonglong uVar8;
uint uVar9;
int cbMultiByte;
undefined *puVar10;
undefined *puVar11;
uint uVar12;
undefined8 uStackY_80;
undefined auStackY_78 [32];
wchar_t local_48 [8];
ulonglong local_38;
undefined8 uStack_30;

uStack_30 = 0x1800ccce3;
local_38 = DAT_18033f868 ^ (ulonglong)local_48;
cVar1 = *param_1;
uVar12 = 0;
pcVar5 = param_1;
for (uVar9 = uVar12; (cVar1 != '\0' && (uVar9 < 0x8000)); uVar9 =
uVar9 + 1) {
  pcVar5 = pcVar5 + 1;
  cVar1 = *pcVar5;
}
cbMultiByte = (uVar9 & 0x7fff) + 1;
uStackY_80 = 0x1800ccd50;
iVar3 = MultiByteToWideChar(0xfde9,8,param_1,cbMultiByte,(LPWSTR)0x0,0);
DVar4 = 8;
if (iVar3 < 1) {
  uStackY_80 = 0x1800ccd5d;
  DVar4 = GetLastError();
  if (DVar4 == 0x3ec) {
uStackY_80 = 0x1800ccd84;
iVar3 =
MultiByteToWideChar(0xfde9,0,param_1,cbMultiByte,(LPWSTR)0x0,0);
DVar4 = 0;
if (0 < iVar3) goto LAB_1800ccdac;
  }
  uStackY_80 = 0x1800ccd91;
  DVar4 = GetLastError();
  puVar10 = auStackY_78;
  puVar11 = auStackY_78;
  if (DVar4 != 0x459) goto LAB_1800cce89;
}
else {
LAB_1800ccdac:
  uVar8 = (longlong)iVar3 * 2 + 0xf;
  if (uVar8 <= (ulonglong)((longlong)iVar3 * 2)) {
uVar8 = 0xff0;
  }
  uStackY_80 = 0x1800ccdd1;
  lVar2 = -(uVar8 & 0xfff0);
  *(int *)( + lVar2) = iVar3;
  *(wchar_t **)( + lVar2) = (wchar_t
*)((longlong)local_48 + lVar2);
  *(undefined8 *)(auStackY_78 + lVar2 + -8) = 0x1800ccdf7;
  iVar3 = MultiByteToWideChar(0xfde9,DVar4,param_1,cbMultiByte,
  *(LPWSTR *)( +
lVar2),
  *(int *)( +
lVar2));
  puVar11 = auStackY_78 + lVar2;
  if (iVar3 == 0) goto LAB_1800cce89;
  cVar1 = *param_2;
  pcVar5 = param_2;
  for (; (cVar1 != '\0' && (uVar12 < 0x8000)); uVar12 = uVar12 + 1) {
pcVar5 = pcVar5 + 1;
cVar1 = *pcVar5;
  }
  *(undefined4 *)( + lVar2) = 8;
  *(wchar_t **)( + lVar2) = local_48;
  *(undefined8 *)(auStackY_78 + lVar2 + -8) = 0x1800cce4d;
  iVar3 = MultiByteToWideChar(0xfde9,0,param_2,(uVar12 & 0x7fff) + 1,
  *(LPWSTR *)( +
lVar2),
  *(int *)( +
lVar2));
  puVar11 = auStackY_78 + lVar2;
  if (iVar3 == 0) goto LAB_1800cce89;
  *(undefined8 *)(auStackY_78 + lVar2 + -8) = 0x1800cce5d;
  pFVar6 = _wfopen((wchar_t *)((longlong)local_48 + lVar2),local_48);
  puVar11 = auStackY_78 + lVar2;
  if (pFVar6 != (FILE *)0x0) goto LAB_1800cce89;
  *(undefined8 *)(auStackY_78 + lVar2 + -8) = 0x1800cce6a;
  piVar7 = _errno();
  puVar10 = auStackY_78 + lVar2;
  if (*piVar7 != 2) {
*(undefined8 *)(auStackY_78 + lVar2 + -8) = 0x1800cce78;
piVar7 = _errno();
puVar10 = auStackY_78 + lVar2;
puVar11 = auStackY_78 + lVar2;
if (*piVar7 != 9) goto LAB_1800cce89;
  }
}
*(undefined8 *)(puVar10 + -8) = 0x1800ccda7;
fopen(param_1,param_2);
puVar11 = puVar10;
LAB_1800cce89:
uVar8 = local_38 ^ (ulonglong)local_48;
*(undefined8 *)(puVar11 + -8) = 0x1800cce95;
FUN_180263660(uVar8);
return;
}

Thanks for helping to at least link it to this openssl source:

https://github.com/openssl/openssl/blob/45f5d51b72a262bf85c4461fbded91485ce6b9da/crypto/o_fopen.c#L38

Since libtcnative.dll is statically-linked, it doesn't even need a
symbol table for internal calls so the openssl_fopen token is completely
lost. 

Re: JVM crashing with caCertificatePath in server.xml

[Michael Osipov]

On 2024/05/17 15:11:58 Christopher Schultz wrote:
> Michael,
> 
> On 5/17/24 03:42, Michael Osipov wrote:
> > On 2024/05/16 21:37:34 Christopher Schultz wrote:
> >> Michael,
> >>
> >> On 5/16/24 12:00, Michael Osipov wrote:
> >>> On 2024/05/16 15:55:04 Andy Arismendi wrote:
>  Ok great! Thank you for taking the time and making the effort to look 
>  into this Michael, much appreciated!
> >>>
> >>> Here is a dynamically linked, patched version until there is an official 
> >>> release: http://home.apache.org/~michaelo/issues/tomcat/openssl-crash/
> >>>
> >>> Please give it a try.
> >>
> >> Since you have produced a debug build of tcnative (and other
> >> components?) could you post the debug trace of the native stack?
> > 
> > Unfortunately I can't. While I have the files with debug symbols I am 
> > limited by https://github.com/mturk/cmsc?tab=readme-ov-file#warning. I 
> > don't have a full blown Visual Studio installed.
> 
> Okay. If you did build with VS, can you get a debug build with a backtrace?

Unfortunately not. Currently, I don't have the capacity to do so.

> I guess you already tracked the crash to openssl_fopen. When I did a 
> decompile of the official binary, I can see the code but it's very 
> difficult to read:
> 
> void FUN_1800cccd0(char *param_1,char *param_2)
> 
> {
>char cVar1;
>longlong lVar2;
>int iVar3;
>DWORD DVar4;
>char *pcVar5;
>FILE *pFVar6;
>int *piVar7;
>ulonglong uVar8;
>uint uVar9;
>int cbMultiByte;
>undefined *puVar10;
>undefined *puVar11;
>uint uVar12;
>undefined8 uStackY_80;
>undefined auStackY_78 [32];
>wchar_t local_48 [8];
>ulonglong local_38;
>undefined8 uStack_30;
> 
>uStack_30 = 0x1800ccce3;
>local_38 = DAT_18033f868 ^ (ulonglong)local_48;
>cVar1 = *param_1;
>uVar12 = 0;
>pcVar5 = param_1;
>for (uVar9 = uVar12; (cVar1 != '\0' && (uVar9 < 0x8000)); uVar9 = 
> uVar9 + 1) {
>  pcVar5 = pcVar5 + 1;
>  cVar1 = *pcVar5;
>}
>cbMultiByte = (uVar9 & 0x7fff) + 1;
>uStackY_80 = 0x1800ccd50;
>iVar3 = MultiByteToWideChar(0xfde9,8,param_1,cbMultiByte,(LPWSTR)0x0,0);
>DVar4 = 8;
>if (iVar3 < 1) {
>  uStackY_80 = 0x1800ccd5d;
>  DVar4 = GetLastError();
>  if (DVar4 == 0x3ec) {
>uStackY_80 = 0x1800ccd84;
>iVar3 = 
> MultiByteToWideChar(0xfde9,0,param_1,cbMultiByte,(LPWSTR)0x0,0);
>DVar4 = 0;
>if (0 < iVar3) goto LAB_1800ccdac;
>  }
>  uStackY_80 = 0x1800ccd91;
>  DVar4 = GetLastError();
>  puVar10 = auStackY_78;
>  puVar11 = auStackY_78;
>  if (DVar4 != 0x459) goto LAB_1800cce89;
>}
>else {
> LAB_1800ccdac:
>  uVar8 = (longlong)iVar3 * 2 + 0xf;
>  if (uVar8 <= (ulonglong)((longlong)iVar3 * 2)) {
>uVar8 = 0xff0;
>  }
>  uStackY_80 = 0x1800ccdd1;
>  lVar2 = -(uVar8 & 0xfff0);
>  *(int *)( + lVar2) = iVar3;
>  *(wchar_t **)( + lVar2) = (wchar_t 
> *)((longlong)local_48 + lVar2);
>  *(undefined8 *)(auStackY_78 + lVar2 + -8) = 0x1800ccdf7;
>  iVar3 = MultiByteToWideChar(0xfde9,DVar4,param_1,cbMultiByte,
>  *(LPWSTR *)( + 
> lVar2),
>  *(int *)( + 
> lVar2));
>  puVar11 = auStackY_78 + lVar2;
>  if (iVar3 == 0) goto LAB_1800cce89;
>  cVar1 = *param_2;
>  pcVar5 = param_2;
>  for (; (cVar1 != '\0' && (uVar12 < 0x8000)); uVar12 = uVar12 + 1) {
>pcVar5 = pcVar5 + 1;
>cVar1 = *pcVar5;
>  }
>  *(undefined4 *)( + lVar2) = 8;
>  *(wchar_t **)( + lVar2) = local_48;
>  *(undefined8 *)(auStackY_78 + lVar2 + -8) = 0x1800cce4d;
>  iVar3 = MultiByteToWideChar(0xfde9,0,param_2,(uVar12 & 0x7fff) + 1,
>  *(LPWSTR *)( + 
> lVar2),
>  *(int *)( + 
> lVar2));
>  puVar11 = auStackY_78 + lVar2;
>  if (iVar3 == 0) goto LAB_1800cce89;
>  *(undefined8 *)(auStackY_78 + lVar2 + -8) = 0x1800cce5d;
>  pFVar6 = _wfopen((wchar_t *)((longlong)local_48 + lVar2),local_48);
>  puVar11 = auStackY_78 + lVar2;
>  if (pFVar6 != (FILE *)0x0) goto LAB_1800cce89;
>  *(undefined8 *)(auStackY_78 + lVar2 + -8) = 0x1800cce6a;
>  piVar7 = _errno();
>  puVar10 = auStackY_78 + lVar2;
>  if (*piVar7 != 2) {
>*(undefined8 *)(auStackY_78 + lVar2 + -8) = 0x1800cce78;
>piVar7 = _errno();
>puVar10 = auStackY_78 + lVar2;
>puVar11 = auStackY_78 + lVar2;
>if (*piVar7 != 9) goto LAB_1800cce89;
>  }
>}
>*(undefined8 *)(puVar10 + -8) = 0x1800ccda7;
>fopen(param_1,param_2);
>puVar11 = puVar10;
> LAB_1800cce89:
>uVar8 = local_38 ^ (ulonglong)local_48;
>*(undefined8 *)(puVar11 + -8) = 0x1800cce95;
>FUN_180263660(uVar8);
>return;
> }
> 
> Thanks for helping to at least link it to this openssl source:
> 
> 

Re: Win10 installation progress

[DdC]

n82...@gmail.com
Dear Chuck Caldarale,
THANKS for your help/ rolling up the sleeves now.
      Some of us have just given up on Windows entirelySure.I have installed 
tomcat also on two unix boxes among which ubuntu,2019 before the transition now 
required.Dealing here with a legacy situation.[[[ For your chuckles:: j2ee.jar 
was used in tomcat4.04 ]]]
THANKS AGAIN.{{{ Purpose of life: helping other people  - you did it. }}}
dennis de champeaux
--
Home page:      rs6.risingnet.net/~ddccMarketing site:  www . OntoOO.comKindle 
books:   Side Effects: Impacts on the 21st 
Century::https://www.amazon.com/-/es/Dennis-Champeaux-ebook/dp/B09MHJ5W48   
Even if not 
true::https://www.amazon.com/-/es/Dennis-Champeaux-ebook/dp/B09Y4WR9J7   9/11:: 
They had the Sun in their 
Eyeshttps://www.amazon.com/11-They-had-their-Eyes-ebook/dp/B0CMQ2WSK9https://www.amazon.nl/dp/B0CMQ2WSK9


 

On Saturday, May 18, 2024 at 10:11:09 PM PDT, Chuck Caldarale 
 wrote:  
 
 
> On May 18, 2024, at 22:40, DdC  wrote:
> 
> Gave up on installing 9.0.88. on Win10. 


Some of us have just given up on Windows entirely…


> Succeeded with  10.1.23 andjdk-18.0.2.1.The lib directory has j2ee.jar, which 
> I have used in earliertomcat versions.


Not lately. I can’t recall when j2ee.jar was last useful, but I’m pretty sure 
it’s been well over a decade. You most likely need to delete it.


> Compilation of a system was OK apart from some warnings because Java 
> haschanged since the code was written.There is a web.xml file in 
> WEB-INF.Invoking a servlet gives a 500 error with the ominous complaint:    
> class su.SUlogin cannot be cast to jakarta.servlet.Servlet    (su.SUlogin is 
> in unnamed module of loader org.apache.catalina    ... )


First, look at the Tomcat migration guides: 
https://tomcat.apache.org/migration.html

You’ll need to review each one, starting with the last version of Tomcat you 
were using, up to the one for 10.1. In particular, when Oracle gave control of 
the Java EE spec to Eclipse, the classes were renamed from javax to jakarta for 
legal reasons, so all code using the old class names must be updated to the 
revised ones. This can be done with a migration tool supplied by Tomcat:

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

or by placing old apps in the webapps-javaee directory rather than webapps and 
letting Tomcat convert them automatically. Look at the documentation for the 
legacyAppBase attribute of the  element:

https://tomcat.apache.org/tomcat-10.1-doc/config/host.html#Common_Attributes

  - Chuck

  

Re: Win10 installation progress

[Chuck Caldarale]

> On May 18, 2024, at 22:40, DdC  wrote:
> 
> Gave up on installing 9.0.88. on Win10. 


Some of us have just given up on Windows entirely…


> Succeeded with  10.1.23 andjdk-18.0.2.1.The lib directory has j2ee.jar, which 
> I have used in earliertomcat versions.


Not lately. I can’t recall when j2ee.jar was last useful, but I’m pretty sure 
it’s been well over a decade. You most likely need to delete it.


> Compilation of a system was OK apart from some warnings because Java 
> haschanged since the code was written.There is a web.xml file in 
> WEB-INF.Invoking a servlet gives a 500 error with the ominous complaint:
> class su.SUlogin cannot be cast to jakarta.servlet.Servlet(su.SUlogin is 
> in unnamed module of loader org.apache.catalina... )


First, look at the Tomcat migration guides: 
https://tomcat.apache.org/migration.html

You’ll need to review each one, starting with the last version of Tomcat you 
were using, up to the one for 10.1. In particular, when Oracle gave control of 
the Java EE spec to Eclipse, the classes were renamed from javax to jakarta for 
legal reasons, so all code using the old class names must be updated to the 
revised ones. This can be done with a migration tool supplied by Tomcat:

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

or by placing old apps in the webapps-javaee directory rather than webapps and 
letting Tomcat convert them automatically. Look at the documentation for the 
legacyAppBase attribute of the  element:

https://tomcat.apache.org/tomcat-10.1-doc/config/host.html#Common_Attributes

  - Chuck

Win10 installation progress

[DdC]

Dear Tomcatters,
Gave up on installing 9.0.88. on Win10.  Succeeded with  10.1.23 
andjdk-18.0.2.1.The lib directory has j2ee.jar, which I have used in 
earliertomcat versions.Compilation of a system was OK apart from some warnings 
because Java haschanged since the code was written.There is a web.xml file in 
WEB-INF.Invoking a servlet gives a 500 error with the ominous complaint:    
class su.SUlogin cannot be cast to jakarta.servlet.Servlet    (su.SUlogin is in 
unnamed module of loader org.apache.catalina    ... )
Looks like that my code is quite out of date.Any suggestion for a fix?Going 
back to an earlier tomcat?
dennis de champeaux
--
Home page:      rs6.risingnet.net/~ddccMarketing site:  www . OntoOO.comKindle 
books:   Side Effects: Impacts on the 21st 
Century::https://www.amazon.com/-/es/Dennis-Champeaux-ebook/dp/B09MHJ5W48   
Even if not 
true::https://www.amazon.com/-/es/Dennis-Champeaux-ebook/dp/B09Y4WR9J7   9/11:: 
They had the Sun in their 
Eyeshttps://www.amazon.com/11-They-had-their-Eyes-ebook/dp/B0CMQ2WSK9https://www.amazon.nl/dp/B0CMQ2WSK9

Re: JVM crashing with caCertificatePath in server.xml

[Christopher Schultz]

Michael,

On 5/17/24 03:42, Michael Osipov wrote:

On 2024/05/16 21:37:34 Christopher Schultz wrote:

Michael,

On 5/16/24 12:00, Michael Osipov wrote:

On 2024/05/16 15:55:04 Andy Arismendi wrote:

Ok great! Thank you for taking the time and making the effort to look into this 
Michael, much appreciated!


Here is a dynamically linked, patched version until there is an official 
release: http://home.apache.org/~michaelo/issues/tomcat/openssl-crash/

Please give it a try.


Since you have produced a debug build of tcnative (and other
components?) could you post the debug trace of the native stack?


Unfortunately I can't. While I have the files with debug symbols I am limited 
by https://github.com/mturk/cmsc?tab=readme-ov-file#warning. I don't have a 
full blown Visual Studio installed.


Okay. If you did build with VS, can you get a debug build with a backtrace?

I guess you already tracked the crash to openssl_fopen. When I did a 
decompile of the official binary, I can see the code but it's very 
difficult to read:


void FUN_1800cccd0(char *param_1,char *param_2)

{
  char cVar1;
  longlong lVar2;
  int iVar3;
  DWORD DVar4;
  char *pcVar5;
  FILE *pFVar6;
  int *piVar7;
  ulonglong uVar8;
  uint uVar9;
  int cbMultiByte;
  undefined *puVar10;
  undefined *puVar11;
  uint uVar12;
  undefined8 uStackY_80;
  undefined auStackY_78 [32];
  wchar_t local_48 [8];
  ulonglong local_38;
  undefined8 uStack_30;

  uStack_30 = 0x1800ccce3;
  local_38 = DAT_18033f868 ^ (ulonglong)local_48;
  cVar1 = *param_1;
  uVar12 = 0;
  pcVar5 = param_1;
  for (uVar9 = uVar12; (cVar1 != '\0' && (uVar9 < 0x8000)); uVar9 = 
uVar9 + 1) {

pcVar5 = pcVar5 + 1;
cVar1 = *pcVar5;
  }
  cbMultiByte = (uVar9 & 0x7fff) + 1;
  uStackY_80 = 0x1800ccd50;
  iVar3 = MultiByteToWideChar(0xfde9,8,param_1,cbMultiByte,(LPWSTR)0x0,0);
  DVar4 = 8;
  if (iVar3 < 1) {
uStackY_80 = 0x1800ccd5d;
DVar4 = GetLastError();
if (DVar4 == 0x3ec) {
  uStackY_80 = 0x1800ccd84;
  iVar3 = 
MultiByteToWideChar(0xfde9,0,param_1,cbMultiByte,(LPWSTR)0x0,0);

  DVar4 = 0;
  if (0 < iVar3) goto LAB_1800ccdac;
}
uStackY_80 = 0x1800ccd91;
DVar4 = GetLastError();
puVar10 = auStackY_78;
puVar11 = auStackY_78;
if (DVar4 != 0x459) goto LAB_1800cce89;
  }
  else {
LAB_1800ccdac:
uVar8 = (longlong)iVar3 * 2 + 0xf;
if (uVar8 <= (ulonglong)((longlong)iVar3 * 2)) {
  uVar8 = 0xff0;
}
uStackY_80 = 0x1800ccdd1;
lVar2 = -(uVar8 & 0xfff0);
*(int *)( + lVar2) = iVar3;
*(wchar_t **)( + lVar2) = (wchar_t 
*)((longlong)local_48 + lVar2);

*(undefined8 *)(auStackY_78 + lVar2 + -8) = 0x1800ccdf7;
iVar3 = MultiByteToWideChar(0xfde9,DVar4,param_1,cbMultiByte,
*(LPWSTR *)( + 
lVar2),
*(int *)( + 
lVar2));

puVar11 = auStackY_78 + lVar2;
if (iVar3 == 0) goto LAB_1800cce89;
cVar1 = *param_2;
pcVar5 = param_2;
for (; (cVar1 != '\0' && (uVar12 < 0x8000)); uVar12 = uVar12 + 1) {
  pcVar5 = pcVar5 + 1;
  cVar1 = *pcVar5;
}
*(undefined4 *)( + lVar2) = 8;
*(wchar_t **)( + lVar2) = local_48;
*(undefined8 *)(auStackY_78 + lVar2 + -8) = 0x1800cce4d;
iVar3 = MultiByteToWideChar(0xfde9,0,param_2,(uVar12 & 0x7fff) + 1,
*(LPWSTR *)( + 
lVar2),
*(int *)( + 
lVar2));

puVar11 = auStackY_78 + lVar2;
if (iVar3 == 0) goto LAB_1800cce89;
*(undefined8 *)(auStackY_78 + lVar2 + -8) = 0x1800cce5d;
pFVar6 = _wfopen((wchar_t *)((longlong)local_48 + lVar2),local_48);
puVar11 = auStackY_78 + lVar2;
if (pFVar6 != (FILE *)0x0) goto LAB_1800cce89;
*(undefined8 *)(auStackY_78 + lVar2 + -8) = 0x1800cce6a;
piVar7 = _errno();
puVar10 = auStackY_78 + lVar2;
if (*piVar7 != 2) {
  *(undefined8 *)(auStackY_78 + lVar2 + -8) = 0x1800cce78;
  piVar7 = _errno();
  puVar10 = auStackY_78 + lVar2;
  puVar11 = auStackY_78 + lVar2;
  if (*piVar7 != 9) goto LAB_1800cce89;
}
  }
  *(undefined8 *)(puVar10 + -8) = 0x1800ccda7;
  fopen(param_1,param_2);
  puVar11 = puVar10;
LAB_1800cce89:
  uVar8 = local_38 ^ (ulonglong)local_48;
  *(undefined8 *)(puVar11 + -8) = 0x1800cce95;
  FUN_180263660(uVar8);
  return;
}

Thanks for helping to at least link it to this openssl source:

https://github.com/openssl/openssl/blob/45f5d51b72a262bf85c4461fbded91485ce6b9da/crypto/o_fopen.c#L38

Since libtcnative.dll is statically-linked, it doesn't even need a 
symbol table for internal calls so the openssl_fopen token is completely 
lost. Also, libtcnative contains all of TCN, APR, and OpenSSL. TCN 
doesn't make direct Win32 calls so that leaves ... all of APR and 
OpenSSL to search for this pattern of calls.


Since you know where the fault is occurring, do you know the native 
call-trace being performed? I'd love to know which component along the 
way is not properly checking for 

Is there any way to add "connection: close" response header via http/1.1 connection after graceful shutdown begin by outside library

[SG H]

Hello all.
I have a question about connection close header in http/1.1 protocol.

While configure k8s environment run Spring Boot Server with Application
Load Balancer(a.k.a ALB)
I heard there are chance to client can get 503 from ALB.

ALB are communicating with a pod using HTTP/1.1 in my case.
When I rolling update pods with new image in k8s, there are must be newly
created pods and terminating pods.
And in terminating pods, Spring Boot are in graceful shutdown phase, so new
connection to these will got RST packet by tomcat embed I guess.
In additional, after graceful shutdown phase, processed requests are not
include connection response header.

Because of above

1. ALB may try to connect Spring Boot in graceful shutdown phase, got RST
and ALB response to client with 503
2. ALB may got response from Spring Boot in graceful shutdown phase which
no connection header.
So, if next request fired, ALB try to reuse current connection because
before connection is recognized as keep-alive, then got RST and ALB
response to client with 503

This may solved by make ALB retry to connect to another instance several
times until got success packet not RST.
But this behavior seems not good because ALB may got RST by another reason.

If I use HTTP/2, I got GOAWAY frame at graceful shutdown phase begun from
connection by async.
And this behavior done by tomcat.
But I can't use HTTP/2 in my environment now.

Seems Golang had a issue similar this before, so it looks like have a code
that add connection: close response header on shutdown phase.

https://cs.opensource.google/go/go/+/refs/tags/go1.22.3:src/net/http/server.go;l=1512
https://cs.opensource.google/go/go/+/refs/tags/go1.22.3:src/net/http/server.go;l=1355
https://cs.opensource.google/go/go/+/refs/tags/go1.22.3:src/net/http/server.go;l=1266
https://cs.opensource.google/go/go/+/refs/tags/go1.22.3:src/net/http/server.go;l=3385

Is there any good solution I can try?

https://github.com/spring-projects/spring-boot/issues/40802

I raised PR on spring boot github about this, and I heard this behavior
might be modified in tomcat side.

I used Embed Tomcat 10.1.17 (in spring boot 3.2.1)
Run on macbook pro m1

Best regards, SaeGon-Heo

Re: JVM crashing with caCertificatePath in server.xml

[Michael Osipov]

On 2024/05/16 21:37:34 Christopher Schultz wrote:
> Michael,
> 
> On 5/16/24 12:00, Michael Osipov wrote:
> > On 2024/05/16 15:55:04 Andy Arismendi wrote:
> >> Ok great! Thank you for taking the time and making the effort to look into 
> >> this Michael, much appreciated!
> > 
> > Here is a dynamically linked, patched version until there is an official 
> > release: http://home.apache.org/~michaelo/issues/tomcat/openssl-crash/
> > 
> > Please give it a try.
> 
> Since you have produced a debug build of tcnative (and other 
> components?) could you post the debug trace of the native stack?

Unfortunately I can't. While I have the files with debug symbols I am limited 
by https://github.com/mturk/cmsc?tab=readme-ov-file#warning. I don't have a 
full blown Visual Studio installed.

M

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

Re: Regarding Tomcat url redirection

[Christopher Schultz]

Lavanya,

On 5/15/24 09:09, lavanya tech wrote:

Hi Chris,





If i remove this from server.xml file i have the below error.

Message java.lang.NoClassDefFoundError: org/towl/indexer/web/Prefix

Description The server encountered an unexpected condition that prevented
it from fulfilling the request.

Exception

jakarta.servlet.ServletException: java.lang.NoClassDefFoundError:
org/towl/indexer/web/Prefix
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:333)
jakarta.servlet.http.HttpServlet.service(HttpServlet.java:658)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51)


That smells like a CLASSPATH problem where your application is not 
actually packaged properly. It could be something else, but it looks 
suspicious.



The "aliasing" will always be weird. IMO it's better to redirect. If you
change to redirect, does everything *work*, even if you don't like how
the browser's URL bar displays?
   --> I tried but it didnot work
ok apart from this tpic , we have one more issue found.


Actually application team, they are deploying two applications one with
towl (which you are already aware) the other one is (towl-app) they have
defined seperate server.xml for both.


Separate server.xml files means that you have to have two separate 
Tomcat processes.



Name:server.lbg.com
Address:  192.168.200.120
Aliases:  example.lbg.com


Name:server.lbg.com
Address:  192.168.200.120
Aliases:  example-app.lbg.com

which means we have two aliases for server.lbg.com , earlier we were
concentrating only on one example.lbg.com , now i wanted to somehow enable
access as the same for the other one also
https://example-app.lbg.com --> https://server.lbg.com:8444/towl-app

So i created iptable rule in the sameway as before redirect 443 to 8444 and
i have the urls working same as example.lbg.com

Both the server.xml files are here

/git/towl/apachetomcat/conf/server.xml
/git/towl-app/apachetomcat/conf/server.xml --> I changed the port of
connectors and everything

But now when i try to access https://example.lbg.com --> I get webpage of
https://example-app.lbg.com and sometimes i get webpage of
https://example.lbg.com after refresh itself which is wierd

May i know why this is happening. If we fix this then I am thinking to
disable the unwated urls leaving the required ones. for example the below
ones. I think that would be easier ? rather than redirecting or aliasing-->
Because we noticed that towl application is already pointing with
https://example.lbg.com

https://server.lbg.com:8443
   https://example-lbg.com:8443
   

https://server.lbg.com:8444
   https://example-lbg.com:8444
   


kindly suggest us a fix.


The best fix is to deploy the two applications normally without any 
funny business. Put both applications into webapps/ with no  
elements in server.xml and let them deploy. Use the correct URLs to 
access them. It's obviously some internal thing to your company because 
nobody is going to use :8443 in the real world.


I'm sorry, but it seems like you are being given arbitrary and weird 
requirements almost as a game.


I'm not sure I can help you any further at this point.

-chris


On Wed, May 15, 2024 at 2:16 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Lavanya,

On 5/15/24 04:43, lavanya tech wrote:

Though to write you privately, regaridng the tomcat url redirection as
the mail chain is getting more big big


It's better to post to the list, so anyone in your situation can learn
from it.


Let me know if its fine for you and here is what I did.

1)  



Don't do this. Just put towl.war into webapps/ and let it auto-deploy.
What you are doing here is double-deploying your "towl" application:
once as "" (ROOT) and once as "/towl". Remove this from server.xml.






Okay.


2) I have towl application and towl.war under webapps directory
3) added  proxy port and proxyname to connector

  
 proxyPort="8443" proxyName="server.lbg.com
">
  
  
  
  
  


Okay.


4) added rewrite.config under conf directory
  > # Redirect everything that is not server.lbg.com
 to
  > # server.lbg.com . Don't worry about /towl

yet.

  > RewriteCond %{HTTP_HOST} !^server\.lbg\.com$
  > RewriteRule ^/(.*) https://server.lbg.com:8443/$1
 [L]
  >
  > # Redirect anything that isn't already going to /towl
  > # to go to /towl
  > RewriteCond %{REQUEST_URI} !^/towl
  > RewriteRule ^/(.*) https://server.lbg.com:8443/towl/$1
 [L]

5) restarted tomcat
6) can access all the urls https://server.lbg.com:8443
, https://server.lbg.com

Re: Regarding Tomcat url redirection

[Christopher Schultz]

Lavanya,

On 5/15/24 09:09, lavanya tech wrote:

Hi Chris,





If i remove this from server.xml file i have the below error.

Message java.lang.NoClassDefFoundError: org/towl/indexer/web/Prefix

Description The server encountered an unexpected condition that prevented
it from fulfilling the request.

Exception

jakarta.servlet.ServletException: java.lang.NoClassDefFoundError:
org/towl/indexer/web/Prefix
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:333)
jakarta.servlet.http.HttpServlet.service(HttpServlet.java:658)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51)


That smells like a CLASSPATH problem where your application is not 
actually packaged properly. It could be something else, but it looks 
suspicious.



The "aliasing" will always be weird. IMO it's better to redirect. If you
change to redirect, does everything *work*, even if you don't like how
the browser's URL bar displays?
   --> I tried but it didnot work
ok apart from this tpic , we have one more issue found.


Actually application team, they are deploying two applications one with
towl (which you are already aware) the other one is (towl-app) they have
defined seperate server.xml for both.


Separate server.xml files means that you have to have two separate 
Tomcat processes.



Name:server.lbg.com
Address:  192.168.200.120
Aliases:  example.lbg.com


Name:server.lbg.com
Address:  192.168.200.120
Aliases:  example-app.lbg.com

which means we have two aliases for server.lbg.com , earlier we were
concentrating only on one example.lbg.com , now i wanted to somehow enable
access as the same for the other one also
https://example-app.lbg.com --> https://server.lbg.com:8444/towl-app

So i created iptable rule in the sameway as before redirect 443 to 8444 and
i have the urls working same as example.lbg.com

Both the server.xml files are here

/git/towl/apachetomcat/conf/server.xml
/git/towl-app/apachetomcat/conf/server.xml --> I changed the port of
connectors and everything

But now when i try to access https://example.lbg.com --> I get webpage of
https://example-app.lbg.com and sometimes i get webpage of
https://example.lbg.com after refresh itself which is wierd

May i know why this is happening. If we fix this then I am thinking to
disable the unwated urls leaving the required ones. for example the below
ones. I think that would be easier ? rather than redirecting or aliasing-->
Because we noticed that towl application is already pointing with
https://example.lbg.com

https://server.lbg.com:8443
   https://example-lbg.com:8443
   

https://server.lbg.com:8444
   https://example-lbg.com:8444
   


kindly suggest us a fix.


The best fix is to deploy the two applications normally without any 
funny business. Put both applications into webapps/ with no  
elements in server.xml and let them deploy. Use the correct URLs to 
access them. It's obviously some internal thing to your company because 
nobody is going to use :8443 in the real world.


I'm sorry, but it seems like you are being given arbitrary and weird 
requirements almost as a game.


I'm not sure I can help you any further at this point.

-chris


On Wed, May 15, 2024 at 2:16 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Lavanya,

On 5/15/24 04:43, lavanya tech wrote:

Though to write you privately, regaridng the tomcat url redirection as
the mail chain is getting more big big


It's better to post to the list, so anyone in your situation can learn
from it.


Let me know if its fine for you and here is what I did.

1)  



Don't do this. Just put towl.war into webapps/ and let it auto-deploy.
What you are doing here is double-deploying your "towl" application:
once as "" (ROOT) and once as "/towl". Remove this from server.xml.






Okay.


2) I have towl application and towl.war under webapps directory
3) added  proxy port and proxyname to connector

  
 proxyPort="8443" proxyName="server.lbg.com
">
  
  
  
  
  


Okay.


4) added rewrite.config under conf directory
  > # Redirect everything that is not server.lbg.com
 to
  > # server.lbg.com . Don't worry about /towl

yet.

  > RewriteCond %{HTTP_HOST} !^server\.lbg\.com$
  > RewriteRule ^/(.*) https://server.lbg.com:8443/$1
 [L]
  >
  > # Redirect anything that isn't already going to /towl
  > # to go to /towl
  > RewriteCond %{REQUEST_URI} !^/towl
  > RewriteRule ^/(.*) https://server.lbg.com:8443/towl/$1
 [L]

5) restarted tomcat
6) can access all the urls https://server.lbg.com:8443
, https://server.lbg.com

Re: JVM crashing with caCertificatePath in server.xml

[Christopher Schultz]

Michael,

On 5/16/24 12:00, Michael Osipov wrote:

On 2024/05/16 15:55:04 Andy Arismendi wrote:

Ok great! Thank you for taking the time and making the effort to look into this 
Michael, much appreciated!


Here is a dynamically linked, patched version until there is an official 
release: http://home.apache.org/~michaelo/issues/tomcat/openssl-crash/

Please give it a try.


Since you have produced a debug build of tcnative (and other 
components?) could you post the debug trace of the native stack?


Ghidra has been *most* unhelpful, here, starting with the fact that it 
doesn't even get the file-offset correct when trying to jump.


-chris

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

Re: JVM crashing with caCertificatePath in server.xml

[Michael Osipov]

On 2024/05/16 15:55:04 Andy Arismendi wrote:
> Ok great! Thank you for taking the time and making the effort to look into 
> this Michael, much appreciated!

Here is a dynamically linked, patched version until there is an official 
release: http://home.apache.org/~michaelo/issues/tomcat/openssl-crash/

Please give it a try.

Michael

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

Re: JVM crashing with caCertificatePath in server.xml

[Andy Arismendi]

Ok great! Thank you for taking the time and making the effort to look into this 
Michael, much appreciated!

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

Re: JVM crashing with caCertificatePath in server.xml

[Michael Osipov]

On 2024/05/15 20:35:08 Michael Osipov wrote:
> On 2024/05/15 14:41:43 Michael Osipov wrote:
> > Good news. I can reproduce on Windows:
> > 15-May-2024 16:40:31.092 INFORMATION [main] 
> > org.apache.coyote.AbstractProtocol.init Initialisiere 
> > ProtocolHandler["https-openssl-apr-18444"]
> > 15-May-2024 16:40:31.144 WARNUNG [main] 
> > org.apache.tomcat.util.net.SSLUtilBase.getEnabled Tomcat interprets the 
> > [ciphers] attribute in a manner consistent with the latest OpenSSL 
> > development branch. Some of the specified [ciphers] are not supported by 
> > the configured SSL engine for this connector (which may use JSSE or an 
> > older OpenSSL version) and have been skipped: 
> > [[TLS_DH_DSS_WITH_AES_256_GCM_SHA384, TLS_DH_RSA_WITH_AES_256_GCM_SHA384, 
> > TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, 
> > TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, TLS_AES_128_CCM_SHA256, 
> > TLS_DH_DSS_WITH_AES_128_GCM_SHA256, TLS_DH_RSA_WITH_AES_128_GCM_SHA256, 
> > TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, 
> > TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256]]
> > #
> > # A fatal error has been detected by the Java Runtime Environment:
> > #
> > #  EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x024928d5cd10, 
> > pid=33136, tid=0x55b8
> > #
> > # JRE version: OpenJDK Runtime Environment (Zulu 8.68.0.21-CA-win64) 
> > (8.0_362-b09) (build 1.8.0_362-b09)
> > # Java VM: OpenJDK 64-Bit Server VM (25.362-b09 mixed mode windows-amd64 
> > compressed oops)
> > # Problematic frame:
> > # C  [tcnative-1.dll+0xccd10]
> > #
> > # Failed to write core dump. Minidumps are not enabled by default on client 
> > versions of Windows
> > #
> > # An error report file with more information is saved as:
> > # C:\Temp\apache-tomcat-9.0.89\hs_err_pid33136.log
> > #
> > # If you would like to submit a bug report, please visit:
> > #   http://www.azul.com/support/
> > # The crash happened outside the Java Virtual Machine in native code.
> > # See problematic frame for where to report the bug.
> > #
> > 
> > I will do a custom build of Tomcat Native and see where it crashes. Stay 
> > tuned.
> 
> Found the bug: It is either a flaw or uncertainty in OpenSSL. Details follow 
> tomorrow.

Details:

Reported the issue upstream: https://github.com/openssl/openssl/issues/24416
I will push a temporary fix until upstream does properly handle NULL input.

Partially OT: After testing here in and out I am convinced that the code after 
SSL_CTX_load_verify_locations() does absolutely not that what the author 
intended to do. The code block messes up CA certification for client 
verification with the request DNs for client cert auth. I will report a 
separate issue because it is unrelated.

Michael

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

Re: JVM crashing with caCertificatePath in server.xml

[Michael Osipov]

On 2024/05/15 14:41:43 Michael Osipov wrote:
> Good news. I can reproduce on Windows:
> 15-May-2024 16:40:31.092 INFORMATION [main] 
> org.apache.coyote.AbstractProtocol.init Initialisiere 
> ProtocolHandler["https-openssl-apr-18444"]
> 15-May-2024 16:40:31.144 WARNUNG [main] 
> org.apache.tomcat.util.net.SSLUtilBase.getEnabled Tomcat interprets the 
> [ciphers] attribute in a manner consistent with the latest OpenSSL 
> development branch. Some of the specified [ciphers] are not supported by the 
> configured SSL engine for this connector (which may use JSSE or an older 
> OpenSSL version) and have been skipped: [[TLS_DH_DSS_WITH_AES_256_GCM_SHA384, 
> TLS_DH_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, 
> TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, TLS_AES_128_CCM_SHA256, 
> TLS_DH_DSS_WITH_AES_128_GCM_SHA256, TLS_DH_RSA_WITH_AES_128_GCM_SHA256, 
> TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256]]
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x024928d5cd10, 
> pid=33136, tid=0x55b8
> #
> # JRE version: OpenJDK Runtime Environment (Zulu 8.68.0.21-CA-win64) 
> (8.0_362-b09) (build 1.8.0_362-b09)
> # Java VM: OpenJDK 64-Bit Server VM (25.362-b09 mixed mode windows-amd64 
> compressed oops)
> # Problematic frame:
> # C  [tcnative-1.dll+0xccd10]
> #
> # Failed to write core dump. Minidumps are not enabled by default on client 
> versions of Windows
> #
> # An error report file with more information is saved as:
> # C:\Temp\apache-tomcat-9.0.89\hs_err_pid33136.log
> #
> # If you would like to submit a bug report, please visit:
> #   http://www.azul.com/support/
> # The crash happened outside the Java Virtual Machine in native code.
> # See problematic frame for where to report the bug.
> #
> 
> I will do a custom build of Tomcat Native and see where it crashes. Stay 
> tuned.

Found the bug: It is either a flaw or uncertainty in OpenSSL. Details follow 
tomorrow.

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

Aw: Re: Logrotation throu CATALINA_OUT_CMD in Tomcat9

[Peter Rader]

> You need to do what the instructions state: create a FIFO and specify its 
> name in the CATALINA_OUT variable. For example, do

Ah, yes,

mkfifo catalina.out

fixed it for me. I had no idea what a fifo is, now I knew.

Kind regards

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

Re: Logrotation throu CATALINA_OUT_CMD in Tomcat9

[Chuck Caldarale]

> On May 15, 2024, at 12:43, Peter Rader  wrote:
> 
> my catalina.out is getting bigger and bigger.


(I should Insert a philosophical discussion on not using stdout for application 
logging here, but I’ll leave that for some other time.)


> In order to have smaller catalina.out I noticed this environment-variable: 
> CATALINA_OUT_CMD
> 
> Inside the catalina.sh is documented:
> 
> # CATALINA_OUT_CMD (Optional) Command which will be executed and receive
> #   as its stdin the stdout and stderr from the Tomcat java
> #   process. If CATALINA_OUT_CMD is set, the value of
> #   CATALINA_OUT will be used as a named pipe.
> #   No default.
> #   Example (all one line)
> #   CATALINA_OUT_CMD="/usr/bin/rotatelogs -f 
> $CATALINA_BASE/logs/catalina.out.%Y-%m-%d.log 86400"
> 
> I try to use that example and export this variable before start of tomcat:
> 
>   export CATALINA_OUT_CMD="/usr/bin/rotatelogs -f 
> /home/tomcat/apache-tomcat-9.0.75/logs/catalina.out.%Y-%m-%d.log 86400" 
> 
> Unfortunately the tomcat does not work anymore, instead this message appear:
> 
>/home/tomcat/apache-tomcat-9.0.75/logs/catalina.out exists and is not a 
> named pipe. Start aborted.


You need to do what the instructions state: create a FIFO and specify its name 
in the CATALINA_OUT variable. For example, do

mkfifo logs/catalina_out.pipe

one time, before starting Tomcat, then add the following to bin/setenv.sh:

export CATALINA_OUT="$CATALINA_HOME/logs/catalina_out.pipe"
export CATALINA_OUT_CMD=“rotatelogs -f 
$CATALINA_HOME/logs/catalina.out.%Y-%m-%d.log 86400"

This causes Tomcat to use the named pipe rather than logs/catalina.out for 
stdout and stderr messages, and then invoke rotatelogs to process the entries. 
As an alternative to setting CATALINA_OUT, you could just delete the existing 
logs/catalina.out file and recreate it as a FIFO, but I wouldn’t recommend it 
due to potential confusion.

  - Chuck

Logrotation throu CATALINA_OUT_CMD in Tomcat9

[Peter Rader]

Hi,

my catalina.out is getting bigger and bigger.

In order to have smaller catalina.out I noticed this environment-variable: 
CATALINA_OUT_CMD

Inside the catalina.sh is documented:

# CATALINA_OUT_CMD (Optional) Command which will be executed and receive
#   as its stdin the stdout and stderr from the Tomcat java
#   process. If CATALINA_OUT_CMD is set, the value of
#   CATALINA_OUT will be used as a named pipe.
#   No default.
#   Example (all one line)
#   CATALINA_OUT_CMD="/usr/bin/rotatelogs -f 
$CATALINA_BASE/logs/catalina.out.%Y-%m-%d.log 86400"

I try to use that example and export this variable before start of tomcat:

   export CATALINA_OUT_CMD="/usr/bin/rotatelogs -f 
/home/tomcat/apache-tomcat-9.0.75/logs/catalina.out.%Y-%m-%d.log 86400" 

Unfortunately the tomcat does not work anymore, instead this message appear:

/home/tomcat/apache-tomcat-9.0.75/logs/catalina.out exists and is not a 
named pipe. Start aborted.
 
Any Ideas?
 
Kind regards

Peter Rader

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

Re: JVM crashing with caCertificatePath in server.xml

[Michael Osipov]

Good news. I can reproduce on Windows:
15-May-2024 16:40:31.092 INFORMATION [main] 
org.apache.coyote.AbstractProtocol.init Initialisiere 
ProtocolHandler["https-openssl-apr-18444"]
15-May-2024 16:40:31.144 WARNUNG [main] 
org.apache.tomcat.util.net.SSLUtilBase.getEnabled Tomcat interprets the 
[ciphers] attribute in a manner consistent with the latest OpenSSL development 
branch. Some of the specified [ciphers] are not supported by the configured SSL 
engine for this connector (which may use JSSE or an older OpenSSL version) and 
have been skipped: [[TLS_DH_DSS_WITH_AES_256_GCM_SHA384, 
TLS_DH_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, 
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, TLS_AES_128_CCM_SHA256, 
TLS_DH_DSS_WITH_AES_128_GCM_SHA256, TLS_DH_RSA_WITH_AES_128_GCM_SHA256, 
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256]]
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x024928d5cd10, pid=33136, 
tid=0x55b8
#
# JRE version: OpenJDK Runtime Environment (Zulu 8.68.0.21-CA-win64) 
(8.0_362-b09) (build 1.8.0_362-b09)
# Java VM: OpenJDK 64-Bit Server VM (25.362-b09 mixed mode windows-amd64 
compressed oops)
# Problematic frame:
# C  [tcnative-1.dll+0xccd10]
#
# Failed to write core dump. Minidumps are not enabled by default on client 
versions of Windows
#
# An error report file with more information is saved as:
# C:\Temp\apache-tomcat-9.0.89\hs_err_pid33136.log
#
# If you would like to submit a bug report, please visit:
#   http://www.azul.com/support/
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

I will do a custom build of Tomcat Native and see where it crashes. Stay tuned.

M

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

Re: Regarding Tomcat url redirection

[lavanya tech]

Hi Chris,

>

If i remove this from server.xml file i have the below error.

Message java.lang.NoClassDefFoundError: org/towl/indexer/web/Prefix

Description The server encountered an unexpected condition that prevented
it from fulfilling the request.

Exception

jakarta.servlet.ServletException: java.lang.NoClassDefFoundError:
org/towl/indexer/web/Prefix
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:333)
jakarta.servlet.http.HttpServlet.service(HttpServlet.java:658)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51)

The "aliasing" will always be weird. IMO it's better to redirect. If you
change to redirect, does everything *work*, even if you don't like how
the browser's URL bar displays?
  --> I tried but it didnot work
ok apart from this tpic , we have one more issue found.


Actually application team, they are deploying two applications one with
towl (which you are already aware) the other one is (towl-app) they have
defined seperate server.xml for both.

Name:server.lbg.com
Address:  192.168.200.120
Aliases:  example.lbg.com


Name:server.lbg.com
Address:  192.168.200.120
Aliases:  example-app.lbg.com

which means we have two aliases for server.lbg.com , earlier we were
concentrating only on one example.lbg.com , now i wanted to somehow enable
access as the same for the other one also
https://example-app.lbg.com --> https://server.lbg.com:8444/towl-app

So i created iptable rule in the sameway as before redirect 443 to 8444 and
i have the urls working same as example.lbg.com

Both the server.xml files are here

/git/towl/apachetomcat/conf/server.xml
/git/towl-app/apachetomcat/conf/server.xml --> I changed the port of
connectors and everything

But now when i try to access https://example.lbg.com --> I get webpage of
https://example-app.lbg.com and sometimes i get webpage of
https://example.lbg.com after refresh itself which is wierd

May i know why this is happening. If we fix this then I am thinking to
disable the unwated urls leaving the required ones. for example the below
ones. I think that would be easier ? rather than redirecting or aliasing-->
Because we noticed that towl application is already pointing with
https://example.lbg.com

   https://server.lbg.com:8443
  https://example-lbg.com:8443
  

   https://server.lbg.com:8444
  https://example-lbg.com:8444
  


kindly suggest us a fix.

Thanks once again for your time

Regards,
Lavanya




On Wed, May 15, 2024 at 2:16 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Lavanya,
>
> On 5/15/24 04:43, lavanya tech wrote:
> > Though to write you privately, regaridng the tomcat url redirection as
> > the mail chain is getting more big big
>
> It's better to post to the list, so anyone in your situation can learn
> from it.
>
> > Let me know if its fine for you and here is what I did.
> >
> > 1)   > autoDeploy="true">
> >
>
> Don't do this. Just put towl.war into webapps/ and let it auto-deploy.
> What you are doing here is double-deploying your "towl" application:
> once as "" (ROOT) and once as "/towl". Remove this from server.xml.
>
> >
> > > className="org.apache.catalina.valves.rewrite.RewriteValve" />
>
> Okay.
>
> > 2) I have towl application and towl.war under webapps directory
> > 3) added  proxy port and proxyname to connector
> >
> >   > protocol="org.apache.coyote.http11.Http11NioProtocol"
> > maxThreads="150" SSLEnabled="true">
> > proxyPort="8443" proxyName="server.lbg.com
> > ">
> >   > className="org.apache.coyote.http2.Http2Protocol" />
> >  
> >   >   certificateKeystorePassword="pass"
> >   type="RSA" />
> >  
> >  
>
> Okay.
>
> > 4) added rewrite.config under conf directory
> >  > # Redirect everything that is not server.lbg.com
> >  to
> >  > # server.lbg.com . Don't worry about /towl
> yet.
> >  > RewriteCond %{HTTP_HOST} !^server\.lbg\.com$
> >  > RewriteRule ^/(.*) https://server.lbg.com:8443/$1
> >  [L]
> >  >
> >  > # Redirect anything that isn't already going to /towl
> >  > # to go to /towl
> >  > RewriteCond %{REQUEST_URI} !^/towl
> >  > RewriteRule ^/(.*) https://server.lbg.com:8443/towl/$1
> >  [L]
> >
> > 5) restarted tomcat
> > 6) can access all the urls https://server.lbg.com:8443
> > , https://server.lbg.com
> > , https://server.lbg.com:8443/towl
> > , https://server.lbg.com/towl
> > 
> > https://example.lbg.com:8443 ,
> > https://example.lbg.com 

Re: JVM crashing with caCertificatePath in server.xml

[Andy Arismendi]

Ah wasn’t sure if attachments worked, log content information below. Yea the 
docs just say directory for trusted CA PEM certificates.


TOMCAT DOCS

https://tomcat.apache.org/tomcat-9.0-doc/config/http.html: caCertificatePath 
(OpenSSL only) Name of the directory that contains the certificates for the 
trusted certificate authorities. The format is PEM-encoded.


CATALINA LOG FINE LEVEL CONTENT

15-May-2024 01:37:45.569 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Server version name:   
Apache Tomcat/9.0.89
15-May-2024 01:37:45.584 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Server built:  
May 3 2024 20:22:11 UTC
15-May-2024 01:37:45.584 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Server version number: 
9.0.89.0
15-May-2024 01:37:45.584 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log OS Name:   
Windows Server 2019
15-May-2024 01:37:45.584 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log OS Version:
10.0
15-May-2024 01:37:45.584 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Architecture:  
amd64
15-May-2024 01:37:45.584 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Java Home: 
D:\Program Files\Java\jre
15-May-2024 01:37:45.584 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log JVM Version:   
1.8.0_322-b06
15-May-2024 01:37:45.584 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log JVM Vendor:
Azul Systems, Inc.
15-May-2024 01:37:45.584 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log CATALINA_BASE: 
D:\Program Files\apache-tomcat
15-May-2024 01:37:45.584 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log CATALINA_HOME: 
D:\Program Files\apache-tomcat
15-May-2024 01:37:45.584 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Command line argument: 
-Djava.util.logging.config.file=D:\Program 
Files\apache-tomcat\conf\logging.properties
15-May-2024 01:37:45.584 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Command line argument: 
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
15-May-2024 01:37:45.584 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Command line argument: 
-Djdk.tls.ephemeralDHKeySize=2048
15-May-2024 01:37:45.584 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Command line argument: 
-Djava.protocol.handler.pkgs=org.apache.catalina.webresources
15-May-2024 01:37:45.584 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Command line argument: 
-Dignore.endorsed.dirs=
15-May-2024 01:37:45.584 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Command line argument: 
-Dcatalina.base=D:\Program Files\apache-tomcat
15-May-2024 01:37:45.584 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Command line argument: 
-Dcatalina.home=D:\Program Files\apache-tomcat
15-May-2024 01:37:45.584 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Command line argument: 
-Djava.io.tmpdir=D:\Program Files\apache-tomcat\temp
15-May-2024 01:37:45.600 INFO [main] 
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded Apache 
Tomcat Native library [1.3.0] using APR version [1.7.4].
15-May-2024 01:37:45.600 INFO [main] 
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR capabilities: 
IPv6 [true], sendfile [true], accept filters [false], random [true], UDS [true].
15-May-2024 01:37:45.600 INFO [main] 
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR/OpenSSL 
configuration: useAprConnector [false], useOpenSSL [true]
15-May-2024 01:37:45.647 FINE [main] 
org.apache.catalina.core.AprLifecycleListener.initializeSSL Current FIPS mode: 
[1]
15-May-2024 01:37:45.647 INFO [main] 
org.apache.catalina.core.AprLifecycleListener.initializeSSL Using OpenSSL with 
the FIPS provider as the default provider
15-May-2024 01:37:45.647 INFO [main] 
org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL 
successfully initialized [OpenSSL 3.0.13 30 Jan 2024]
15-May-2024 01:37:45.756 FINE [main] 
org.apache.tomcat.util.modeler.Registry.getMBeanServer Created MBeanServer
15-May-2024 01:37:46.069 FINE [main] 
org.apache.catalina.util.LifecycleBase.setStateInternal Setting state for 
[org.apache.catalina.deploy.NamingResourcesImpl@5e955596] to [INITIALIZING]
15-May-2024 01:37:46.084 FINE [main] 
org.apache.catalina.util.LifecycleBase.setStateInternal Setting state for 
[org.apache.catalina.deploy.NamingResourcesImpl@5e955596] to [INITIALIZED]
15-May-2024 01:37:46.116 FINE [main] 
org.apache.catalina.util.LifecycleBase.setStateInternal Setting state for 
[StandardService[Catalina]] to [INITIALIZING]
15-May-2024 01:37:46.116 FINE [main] 
org.apache.catalina.util.LifecycleBase.setStateInternal Setting state for 

Re: Regarding Tomcat url redirection

[Christopher Schultz]

Lavanya,

On 5/15/24 04:43, lavanya tech wrote:
Though to write you privately, regaridng the tomcat url redirection as 
the mail chain is getting more big big


It's better to post to the list, so anyone in your situation can learn 
from it.



Let me know if its fine for you and here is what I did.

1)      autoDeploy="true">

           


Don't do this. Just put towl.war into webapps/ and let it auto-deploy. 
What you are doing here is double-deploying your "towl" application: 
once as "" (ROOT) and once as "/towl". Remove this from server.xml.



           
           className="org.apache.catalina.valves.rewrite.RewriteValve" />


Okay.


2) I have towl application and towl.war under webapps directory
3) added  proxy port and proxyname to connector

     protocol="org.apache.coyote.http11.Http11NioProtocol"

                maxThreads="150" SSLEnabled="true">
                proxyPort="8443" proxyName="server.lbg.com 
">
         className="org.apache.coyote.http2.Http2Protocol" />

         
             
         
     


Okay.


4) added rewrite.config under conf directory
 > # Redirect everything that is not server.lbg.com 
 to

 > # server.lbg.com . Don't worry about /towl yet.
 > RewriteCond %{HTTP_HOST} !^server\.lbg\.com$
 > RewriteRule ^/(.*) https://server.lbg.com:8443/$1 
 [L]

 >
 > # Redirect anything that isn't already going to /towl
 > # to go to /towl
 > RewriteCond %{REQUEST_URI} !^/towl
 > RewriteRule ^/(.*) https://server.lbg.com:8443/towl/$1 
 [L]


5) restarted tomcat
6) can access all the urls https://server.lbg.com:8443 
, https://server.lbg.com 
, https://server.lbg.com:8443/towl 
, https://server.lbg.com/towl 

https://example.lbg.com:8443 , 
https://example.lbg.com , 
https://example.lbg.com:8443/towl , 
https://example.lbg.com/towl 


Unfortunately aliasing still doesnot work https://example.lbg.com 
 --> https://server.lbg.com:8443/towl 
 and many urls works


The "aliasing" will always be weird. IMO it's better to redirect. If you 
change to redirect, does everything *work*, even if you don't like how 
the browser's URL bar displays?


-chris

On Tue, May 14, 2024 at 11:38 PM Christopher Schultz 
mailto:ch...@christopherschultz.net>> wrote:


Lavanya,

On 5/14/24 15:11, lavanya tech wrote:
 > You are right. We need aliasing here which means the URL in the
browser
 > does not change.
 > May I know where should I put the below rewrite files ?
 >
 > # Redirect everything that is not server.lbg.com
 to
 > # server.lbg.com . Don't worry about /towl
yet.
 > RewriteCond %{HTTP_HOST} !^server\.lbg\.com$
 > RewriteRule ^/(.*) https://server.lbg.com:8443/$1
 [R=301,L]
 >
 > # Redirect anything that isn't already going to /towl
 > # to go to /towl
 > RewriteCond %{REQUEST_URI} !^/towl
 > RewriteRule ^/(.*) https://server.lbg.com:8443/towl/$1
 [R=301,L]

AIUI, you can put all of the above in conf/rewrite.config and configure
the  under your  just as you had it before.

If you want aliasing and not redirection, then you don't want the [R]
flag. IMO, you should really do a redirect. If you don't, then the
application and the browser disagree about the base URL and all
kinds of
things like that.

-chris

 > On Tuesday, May 14, 2024, Christopher Schultz
mailto:ch...@christopherschultz.net>>
 > wrote:
 >
 >> Lavanya,
 >>
 >> On 5/14/24 09:12, lavanya tech wrote:
 >>
 >>> IMHO removing the port number is always the preferred solution
— I never
  did it
 
 
 > can we achieve this with tomcat or we need to setup an
reverse proxy
 > here.
 >
 >
  Your application uses whatever internal URLs it wants. Are you
building
  those yourself, or are you asking Tomcat for the e.g.
hostname, etc.? If
  it's Tomcat, this is where the proxyName and proxyPort come in.
 
 >>>
 >>>    - Yes, I have not built these UrLs before. It’s was working
from the
 >>> very
 >>> beginning. As. I mentioned we are not able to reach goal or
whatever.
 >>>
 >>> Rather than saying redirection, I would say it’s aliasing.
 >>>
 >>
 >> Please be specific. "Aliasing" (to me) means "the URL does to
the right
 >> place but doesn't change in the browser's URL" and "redirection" (to
 >> 

Re: JVM crashing with caCertificatePath in server.xml

[Michael Osipov]

On 2024/05/15 01:51:41 Andy Arismendi wrote:
> ADDITIONAL ENVIRONMENT INFO UPDATE:
> 
> libtcnative: org.apache.catalina.core.AprLifecycleListener.lifecycleEvent 
> Loaded Apache Tomcat Native library [1.3.0] using APR version [1.7.4].
> 
> CRASH LOG
> 
> See enclosed: hs_err_pid4464.log
> 
> c_rehash.pl
> 
> I didn’t have perl, tried strawberry perl, it didn’t seem to create symlinks 
> on Windows so I do it with a powershell using "openssl x509 -subject_hash 
> -fingerprint -noout -in " making symlinks in the same directory for 
> each CA cert PEM e.g. a655d288.0 (link) -> cert.pem (file). This didn’t seem 
> to make a difference though, JVM still crashed.

To make sure I have just tried:
> 8981 2024-05-15T10:26:58.717 INFORMATION [main] 
> org.apache.catalina.startup.VersionLoggerListener.log Server version name:   
> Apache Tomcat/9.0.89
> 8982 2024-05-15T10:26:58.722 INFORMATION [main] 
> org.apache.catalina.startup.VersionLoggerListener.log Server built:  
> May 3 2024 20:22:11 UTC
> 8983 2024-05-15T10:26:58.722 INFORMATION [main] 
> org.apache.catalina.startup.VersionLoggerListener.log Server version number: 
> 9.0.89.0
> 8984 2024-05-15T10:26:58.722 INFORMATION [main] 
> org.apache.catalina.startup.VersionLoggerListener.log OS Name:   
> HP-UX
> 8985 2024-05-15T10:26:58.723 INFORMATION [main] 
> org.apache.catalina.startup.VersionLoggerListener.log OS Version:
> B.11.31
> 8986 2024-05-15T10:26:58.723 INFORMATION [main] 
> org.apache.catalina.startup.VersionLoggerListener.log Architecture:  
> IA64N
> 8987 2024-05-15T10:26:58.723 INFORMATION [main] 
> org.apache.catalina.startup.VersionLoggerListener.log Java Home: 
> /opt/java8/jre
> 8988 2024-05-15T10:26:58.723 INFORMATION [main] 
> org.apache.catalina.startup.VersionLoggerListener.log JVM Version:   
> 1.8.0.27-hp-ux-b1
> 8989 2024-05-15T10:26:58.724 INFORMATION [main] 
> org.apache.catalina.startup.VersionLoggerListener.log JVM Vendor:
> Hewlett Packard Enterprise Company
> 8990 2024-05-15T10:26:58.724 INFORMATION [main] 
> org.apache.catalina.startup.VersionLoggerListener.log CATALINA_BASE: 
> /var/opt/tomcat-services
> 8991 2024-05-15T10:26:58.724 INFORMATION [main] 
> org.apache.catalina.startup.VersionLoggerListener.log CATALINA_HOME: 
> /opt/ports/apache-tomcat-9.0.89
> 9015 2024-05-15T10:26:58.733 INFORMATION [main] 
> org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded Apache 
> Tomcat Native library [1.3.0] using APR version [1.7.4].
> 9016 2024-05-15T10:26:58.733 INFORMATION [main] 
> org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR 
> capabilities: IPv6 [true], sendfile [true], accept filters [false], random 
> [true], UDS [true].
> 9017 2024-05-15T10:26:58.733 INFORMATION [main] 
> org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR/OpenSSL 
> configuration: useAprConnector [true], useOpenSSL [true]
> 9018 2024-05-15T10:26:58.816 INFORMATION [main] 
> org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL 
> successfully initialized [OpenSSL 3.0.13 30 Jan 2024]

With my smartcard it just works:
>  maxParameterCount="1000"
> maxHttpHeaderSize="24576" maxThreads="250"
> SSLEnabled="true" scheme="https" secure="true"
> defaultSSLHostConfigName="...">
>  honorCipherOrder="true" disableSessionTickets="true"
> certificateVerification="optional" certificateVerificationDepth="5"
> 
> ciphers="HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK:!DSS:!SHA1:!SHA256:!SHA384"
> caCertificatePath="/opt/openssl/certs">
>  certificateKeyFile="/opt/openssl/.../key.crt"
> certificateKeyPasswordFile="/opt/openssl/.../password" type="RSA" 
> />
> 
>  value="/opt/openssl/siemens-medium+strong-clientcert-cacerts.crt" />
> 
> 
> 
> 

M

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

Re: JVM crashing with caCertificatePath in server.xml

[Michael Osipov]

On 2024/05/14 20:27:02 Christopher Schultz wrote:
> 
> 
> On 5/14/24 15:23, Andy Arismendi wrote:
> > Sure thing -
> > 
> > ADDITIONAL ENVIRONMENT INFO:
> > 
> > libtcnative: tcnative-1.dll is included in the Tomcat 9.0.89 64-bit Windows 
> > zip download, not sure about the version...
> > OpenSSL version: 3.0.13 30 Jan 2024 (Library: OpenSSL 3.0.13 30 Jan 2024) 
> > (with FIPS 140-2)
> > 
> > Regarding expecting a directory of certificate hash files, I wasn’t
> > aware of this, assumed it would pick up CA cert PEM files in a
> > directory.
> 
> The Tomcat documentation does say this just needs to be a directory full 
> of PEM files. I can trace through the code to see if it's more like what 
> Michael-O posted. Honestly, the whole idea of having to run c_rehash is 
> a stupid hack for stupid programs. You should never have to do that. :/

If the docs say so, then we need to fix the docs because all path input in 
OpenSSL expects simplified subject hashes. Anything else will not work/will be 
ignored. Use strace/truss/etc. and you will see what OpenSSL will try to read. 
"openssl s_server" will do the trick here for you.

Michael

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

Re: JVM crashing with caCertificatePath in server.xml

[Michael Osipov]

On 2024/05/15 01:51:41 Andy Arismendi wrote:
> ADDITIONAL ENVIRONMENT INFO UPDATE:
> 
> libtcnative: org.apache.catalina.core.AprLifecycleListener.lifecycleEvent 
> Loaded Apache Tomcat Native library [1.3.0] using APR version [1.7.4].
> 
> CRASH LOG
> 
> See enclosed: hs_err_pid4464.log

Attachments are stripped. You not to upload it somewhere or send via email.

Michael

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

Re: JVM crashing with caCertificatePath in server.xml

[Andy Arismendi]

ADDITIONAL ENVIRONMENT INFO UPDATE:

libtcnative: org.apache.catalina.core.AprLifecycleListener.lifecycleEvent 
Loaded Apache Tomcat Native library [1.3.0] using APR version [1.7.4].

CRASH LOG

See enclosed: hs_err_pid4464.log

c_rehash.pl

I didn’t have perl, tried strawberry perl, it didn’t seem to create symlinks on 
Windows so I do it with a powershell using "openssl x509 -subject_hash 
-fingerprint -noout -in " making symlinks in the same directory for 
each CA cert PEM e.g. a655d288.0 (link) -> cert.pem (file). This didn’t seem to 
make a difference though, JVM still crashed.

-Andy


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

Re: Regarding Tomcat url redirection

[Christopher Schultz]

Lavanya,

On 5/14/24 15:11, lavanya tech wrote:

You are right. We need aliasing here which means the URL in the browser
does not change.
May I know where should I put the below rewrite files ?

# Redirect everything that is not server.lbg.com to
# server.lbg.com. Don't worry about /towl yet.
RewriteCond %{HTTP_HOST} !^server\.lbg\.com$
RewriteRule ^/(.*) https://server.lbg.com:8443/$1 [R=301,L]

# Redirect anything that isn't already going to /towl
# to go to /towl
RewriteCond %{REQUEST_URI} !^/towl
RewriteRule ^/(.*) https://server.lbg.com:8443/towl/$1 [R=301,L]


AIUI, you can put all of the above in conf/rewrite.config and configure 
the  under your  just as you had it before.


If you want aliasing and not redirection, then you don't want the [R] 
flag. IMO, you should really do a redirect. If you don't, then the 
application and the browser disagree about the base URL and all kinds of 
things like that.


-chris


On Tuesday, May 14, 2024, Christopher Schultz 
wrote:


Lavanya,

On 5/14/24 09:12, lavanya tech wrote:


IMHO removing the port number is always the preferred solution — I never

did it



can we achieve this with tomcat or we need to setup an reverse proxy
here.



Your application uses whatever internal URLs it wants. Are you building
those yourself, or are you asking Tomcat for the e.g. hostname, etc.? If
it's Tomcat, this is where the proxyName and proxyPort come in.



   - Yes, I have not built these UrLs before. It’s was working from the
very
beginning. As. I mentioned we are not able to reach goal or whatever.

Rather than saying redirection, I would say it’s aliasing.



Please be specific. "Aliasing" (to me) means "the URL does to the right
place but doesn't change in the browser's URL" and "redirection" (to
everybody) means "HTTP 301 or 302 response to a new URL".

Instead of moving applications or changing tomcat configuration it’s easier

to achieve with reverse proxy ?

https://example.lbg.com/ to https://server.lbg.com:8443/towl



This will be a nightmare. Do not try to rewrite URLs using a reverse
proxy. You should redirect users to the right place if necessary. You can
use a reverse-proxy if you want, but it won't be any less complicated than
having Tomcat do it.

I think your rewrite.config file just needs a few tweaks:

# Redirect everything that is not server.lbg.com to
# server.lbg.com. Don't worry about /towl yet.
RewriteCond %{HTTP_HOST} !^server\.lbg\.com$
RewriteRule ^/(.*) https://server.lbg.com:8443/$1 [R=301,L]

# Redirect anything that isn't already going to /towl
# to go to /towl
RewriteCond %{REQUEST_URI} !^/towl
RewriteRule ^/(.*) https://server.lbg.com:8443/towl/$1 [R=301,L]

The application should be deployed as towl.war (or towl/ directory). You
should listen on ports 80, 443, and 8443, and you should always end up at
the right place. You should have proxyPort="8443" and proxyName="
server.lbg.com" in your .

You will not need a ROOT context, since the rewrite will take care of that
for you.

-chris

On Mon, May 13, 2024 at 10:17 PM lavanya tech 

wrote:

Hi Chris,

Sorry, If I did confuse. It’s important that
https://server.lbg.com:8443/towl is always working. Goal is not to
disable /towl, but just redirect or aliasing

https//example.lbg.com/ to https://server.lbg.com:8443/towl




Thanks,
Lavanya

On Monday, May 13, 2024, Christopher Schultz <
ch...@christopherschultz.net



wrote:


Lavanya,

On 5/13/24 05:57, lavanya tech wrote:

Somehow made it work now i can only access urls as you mentioned before
https://example.lbg.com and https://server.lbg.com with port 8443 and
with
out

 https://example.lbg.com/towl and https://server.lbg.com/towl --> I
have an
error now File not found.

So i think we need to make work https://example.lbg.com/ to
https://server.lbg.com/towl


I'm sorry, I'm still confused as to which way you want things.

Do you want to redirect /towl -> / or do you want to redirect / - >
/towl?

Or does it depend upon the hostname? It would really be better if you
could settle on one specific beahvior.

-chris

On Mon, May 13, 2024 at 9:41 AM lavanya tech 

wrote:

Hi Chris,


Where are you defining the RewriteValve itself?

Defined rewritevalve here
  

  
 resource="conf/rewrite.config" />

2) reated rewrite.config and added as below under conf/

 RewriteCond %{REQUEST_URI} ^/towl/(.*)
 RewriteRule ^/towl/(.*) https://example.lbg.com/%1 [R]

3) After renaming towl to ROOT -> /webapps/ROOT/WEB-INF/web.xml ( I
already have this mappings /* in web.xml file)

   
  
Logging Area

Authentication for registered users.

/*
/api/v1/search 
/api/v1/suggest/* 
  

LDAP_USER
api



4) Restarted Tomcat, Then I cannot access
https://server.lbg.com:8443/towl
--> Have below error

Message java.nio.file.NoSuchFileException:

Re: JVM crashing with caCertificatePath in server.xml

[Christopher Schultz]

On 5/14/24 15:23, Andy Arismendi wrote:

Sure thing -

ADDITIONAL ENVIRONMENT INFO:

libtcnative: tcnative-1.dll is included in the Tomcat 9.0.89 64-bit Windows zip 
download, not sure about the version...
OpenSSL version: 3.0.13 30 Jan 2024 (Library: OpenSSL 3.0.13 30 Jan 2024) (with 
FIPS 140-2)

Regarding expecting a directory of certificate hash files, I wasn’t
aware of this, assumed it would pick up CA cert PEM files in a
directory.


The Tomcat documentation does say this just needs to be a directory full 
of PEM files. I can trace through the code to see if it's more like what 
Michael-O posted. Honestly, the whole idea of having to run c_rehash is 
a stupid hack for stupid programs. You should never have to do that. :/



I would however not expect this or an empty directory to crash the
JVM however…

+1

Are you able to provide a better backtrace than 
"libtcnative.dll++0xccd10"? A Java stack trace would be great, but a 
native one would be even better.


-chris

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

Re: JVM crashing with caCertificatePath in server.xml

[Michael Osipov]

On 2024/05/14 19:23:47 Andy Arismendi wrote:
> Sure thing - 
> 
> ADDITIONAL ENVIRONMENT INFO:
> 
> libtcnative: tcnative-1.dll is included in the Tomcat 9.0.89 64-bit Windows 
> zip download, not sure about the version...
> OpenSSL version: 3.0.13 30 Jan 2024 (Library: OpenSSL 3.0.13 30 Jan 2024) 
> (with FIPS 140-2)

Have a look at catalina.out, it should be 1.3.0, I guess.

> Regarding expecting a directory of certificate hash files, I wasn’t aware of 
> this, assumed it would pick up CA cert PEM files in a directory. I would 
> however not expect this or an empty directory to crash the JVM however…

Nope, it won't. See SSL_CTX_load_verify_locations at 
https://www.openssl.org/docs/manmaster/man3/SSL_CTX_load_verify_locations.html:
If CApath is not NULL, it points to a directory containing CA certificates in 
PEM format. The files each contain one CA certificate. The files are looked up 
by the CA subject name hash value, which must hence be available. If more than 
one CA certificate with the same name hash value exist, the extension must be 
different (e.g. 9d66eef0.0, 9d66eef0.1 etc). The search is performed in the 
ordering of the extension number, regardless of other properties of the 
certificates. Use the c_rehash utility to create the necessary links.

Please don't forget the log file. The issue is somewhere here: 
https://github.com/apache/tomcat-native/blob/43ddd1e8059528454110198ca0d7d191322beeaf/native/src/sslcontext.c#L673-L738

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

Re: JVM crashing with caCertificatePath in server.xml

[Andy Arismendi]

Sure thing - 

ADDITIONAL ENVIRONMENT INFO:

libtcnative: tcnative-1.dll is included in the Tomcat 9.0.89 64-bit Windows zip 
download, not sure about the version...
OpenSSL version: 3.0.13 30 Jan 2024 (Library: OpenSSL 3.0.13 30 Jan 2024) (with 
FIPS 140-2)

Regarding expecting a directory of certificate hash files, I wasn’t aware of 
this, assumed it would pick up CA cert PEM files in a directory. I would 
however not expect this or an empty directory to crash the JVM however…

-Andy


On May 14, 2024, at 2:53 PM, Michael Osipov  wrote:

Please provide the log file, the OpenSSL version used and the libtcnative 
version used. 
Please note that caCertificatePath expects a directory with certificate hash 
files. Plain certs won't work.

M

Re: Regarding Tomcat url redirection

[lavanya tech]

Hi Chris,

You are right. We need aliasing here which means the URL in the browser
does not change.
May I know where should I put the below rewrite files ?

# Redirect everything that is not server.lbg.com to
# server.lbg.com. Don't worry about /towl yet.
RewriteCond %{HTTP_HOST} !^server\.lbg\.com$
RewriteRule ^/(.*) https://server.lbg.com:8443/$1 [R=301,L]

# Redirect anything that isn't already going to /towl
# to go to /towl
RewriteCond %{REQUEST_URI} !^/towl
RewriteRule ^/(.*) https://server.lbg.com:8443/towl/$1 [R=301,L]

Thanks,
Lavanya

On Tuesday, May 14, 2024, Christopher Schultz 
wrote:

> Lavanya,
>
> On 5/14/24 09:12, lavanya tech wrote:
>
>> IMHO removing the port number is always the preferred solution — I never
>>> did it
>>>
>>>
 can we achieve this with tomcat or we need to setup an reverse proxy
 here.


>>> Your application uses whatever internal URLs it wants. Are you building
>>> those yourself, or are you asking Tomcat for the e.g. hostname, etc.? If
>>> it's Tomcat, this is where the proxyName and proxyPort come in.
>>>
>>
>>   - Yes, I have not built these UrLs before. It’s was working from the
>> very
>> beginning. As. I mentioned we are not able to reach goal or whatever.
>>
>> Rather than saying redirection, I would say it’s aliasing.
>>
>
> Please be specific. "Aliasing" (to me) means "the URL does to the right
> place but doesn't change in the browser's URL" and "redirection" (to
> everybody) means "HTTP 301 or 302 response to a new URL".
>
> Instead of moving applications or changing tomcat configuration it’s easier
>> to achieve with reverse proxy ?
>>
>> https://example.lbg.com/ to https://server.lbg.com:8443/towl
>>
>
> This will be a nightmare. Do not try to rewrite URLs using a reverse
> proxy. You should redirect users to the right place if necessary. You can
> use a reverse-proxy if you want, but it won't be any less complicated than
> having Tomcat do it.
>
> I think your rewrite.config file just needs a few tweaks:
>
> # Redirect everything that is not server.lbg.com to
> # server.lbg.com. Don't worry about /towl yet.
> RewriteCond %{HTTP_HOST} !^server\.lbg\.com$
> RewriteRule ^/(.*) https://server.lbg.com:8443/$1 [R=301,L]
>
> # Redirect anything that isn't already going to /towl
> # to go to /towl
> RewriteCond %{REQUEST_URI} !^/towl
> RewriteRule ^/(.*) https://server.lbg.com:8443/towl/$1 [R=301,L]
>
> The application should be deployed as towl.war (or towl/ directory). You
> should listen on ports 80, 443, and 8443, and you should always end up at
> the right place. You should have proxyPort="8443" and proxyName="
> server.lbg.com" in your .
>
> You will not need a ROOT context, since the rewrite will take care of that
> for you.
>
> -chris
>
> On Mon, May 13, 2024 at 10:17 PM lavanya tech 
>>> wrote:
>>>
>>> Hi Chris,
>>>
>>> Sorry, If I did confuse. It’s important that
>>> https://server.lbg.com:8443/towl is always working. Goal is not to
>>> disable /towl, but just redirect or aliasing
>>>
>>> https//example.lbg.com/ to https://server.lbg.com:8443/towl
>>>
>>>
>>>
>>>
>>> Thanks,
>>> Lavanya
>>>
>>> On Monday, May 13, 2024, Christopher Schultz <
>>> ch...@christopherschultz.net
>>>

 wrote:
>>>
>>> Lavanya,
>>>
>>> On 5/13/24 05:57, lavanya tech wrote:
>>>
>>> Somehow made it work now i can only access urls as you mentioned before
>>> https://example.lbg.com and https://server.lbg.com with port 8443 and
>>> with
>>> out
>>>
>>> https://example.lbg.com/towl and https://server.lbg.com/towl --> I
>>> have an
>>> error now File not found.
>>>
>>> So i think we need to make work https://example.lbg.com/ to
>>> https://server.lbg.com/towl
>>>
>>>
>>> I'm sorry, I'm still confused as to which way you want things.
>>>
>>> Do you want to redirect /towl -> / or do you want to redirect / - >
>>> /towl?
>>>
>>> Or does it depend upon the hostname? It would really be better if you
>>> could settle on one specific beahvior.
>>>
>>> -chris
>>>
>>> On Mon, May 13, 2024 at 9:41 AM lavanya tech 
>>>
>>> wrote:
>>>
>>> Hi Chris,
>>>
>>>
>>> Where are you defining the RewriteValve itself?
>>>
>>> Defined rewritevalve here
>>>  >>unpackWARs="true" autoDeploy="true">
>>>
>>>  >> className="org.apache.catalina.valves.rewrite.RewriteValve" />
>>> resource="conf/rewrite.config" />
>>>
>>> 2) reated rewrite.config and added as below under conf/
>>>
>>> RewriteCond %{REQUEST_URI} ^/towl/(.*)
>>> RewriteRule ^/towl/(.*) https://example.lbg.com/%1 [R]
>>>
>>> 3) After renaming towl to ROOT -> /webapps/ROOT/WEB-INF/web.xml ( I
>>> already have this mappings /* in web.xml file)
>>>
>>>   
>>>  
>>>Logging Area
>>>
>>>Authentication for registered users.
>>>
>>>/*
>>>/api/v1/search 
>>>/api/v1/suggest/* 
>>>  
>>>
>>>LDAP_USER
>>>api
>>>
>>>  

Re: JVM crashing with caCertificatePath in server.xml

[Michael Osipov]

On 2024/05/14 18:21:36 Andy Arismendi wrote:
> Hi, just ran into this today. The JVM is crashing when caCertificatePath is 
> added to server.xml. I tried the latest Zulu JRE 8 and 11 but still had the 
> crash.
> 
> 
> ENVIRONMENT
> 
> Tomcat: 9.0.89 (64-bit Windows zip)
> OS: Windows Server 2019
> JVM:
> openjdk version "1.8.0_322"
> OpenJDK Runtime Environment (Zulu 8.60.0.21-CA-win64) (build 1.8.0_322-b06)
> OpenJDK 64-Bit Server VM (Zulu 8.60.0.21-CA-win64) (build 25.322-b06, mixed 
> mode)
> 
> 
> CRASH INFO
> 
> When caCertificatePath is present in server.xml and points to a valid 
> directory (empty or with PEM files) the JVM crashes during Tomcat startup. 
> This is the JVM console output:
> 
> 14-May-2024 17:34:58.443 INFO [main] org.apache.coyote.AbstractProtocol.init 
> Initializing ProtocolHandler ["https-openssl-nio2-1.2.3.4-443"]
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x0001800ccd10, 
> pid=1244, tid=0x0ab0
> #
> # JRE version: OpenJDK Runtime Environment (Zulu 8.60.0.21-CA-win64) 
> (8.0_322-b06) (build 1.8.0_322-b06)
> # Java VM: OpenJDK 64-Bit Server VM (25.322-b06 mixed mode windows-amd64 
> compressed oops)
> # Problematic frame:
> # C  [tcnative-1.dll+0xccd10]
> #
> # Core dump written. Default location: D:\Program 
> Files\apache-tomcat\bin\hs_err_pid1244.mdmp
> #
> # An error report file with more information is saved as:
> # D:\Program Files\apache-tomcat\bin\hs_err_pid1244.log
> #
> # If you would like to submit a bug report, please visit:
> #   http://www.azul.com/support/
> # The crash happened outside the Java Virtual Machine in native code.
> # See problematic frame for where to report the bug.
> #
> 
> 
> CONFIG INFO
> 
> Here’s the server.xml that causes the JVM crash. 
> 
>  maxThreads="1000" port="443" scheme="https" secure="true" SSLEnabled="true" 
> allowTrace="false" xpoweredBy="false" address="1.2.3.4" acceptCount="1" 
> socket.rxBufSize="131072" socket.txBufSize="131072" minSpareThreads="100" 
> maxConnections="1">
>ciphers="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA"
>  disableCompression="true" disableSessionTickets="false" 
> honorCipherOrder="true" caCertificatePath="C:\PKI\CA">
>  certificateKeyFile="C:\PKI\server.key" 
> certificateChainFile="C:\PKI\server-chain.pem"/>
>   
> 

Please provide the log file, the OpenSSL version used and the libtcnative 
version used. 
Please note that caCertificatePath expects a directory with certificate hash 
files. Plain certs won't work.

M

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

JVM crashing with caCertificatePath in server.xml

[Andy Arismendi]

Hi, just ran into this today. The JVM is crashing when caCertificatePath is 
added to server.xml. I tried the latest Zulu JRE 8 and 11 but still had the 
crash.


ENVIRONMENT

Tomcat: 9.0.89 (64-bit Windows zip)
OS: Windows Server 2019
JVM:
openjdk version "1.8.0_322"
OpenJDK Runtime Environment (Zulu 8.60.0.21-CA-win64) (build 1.8.0_322-b06)
OpenJDK 64-Bit Server VM (Zulu 8.60.0.21-CA-win64) (build 25.322-b06, mixed 
mode)


CRASH INFO

When caCertificatePath is present in server.xml and points to a valid directory 
(empty or with PEM files) the JVM crashes during Tomcat startup. This is the 
JVM console output:

14-May-2024 17:34:58.443 INFO [main] org.apache.coyote.AbstractProtocol.init 
Initializing ProtocolHandler ["https-openssl-nio2-1.2.3.4-443"]
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x0001800ccd10, pid=1244, 
tid=0x0ab0
#
# JRE version: OpenJDK Runtime Environment (Zulu 8.60.0.21-CA-win64) 
(8.0_322-b06) (build 1.8.0_322-b06)
# Java VM: OpenJDK 64-Bit Server VM (25.322-b06 mixed mode windows-amd64 
compressed oops)
# Problematic frame:
# C  [tcnative-1.dll+0xccd10]
#
# Core dump written. Default location: D:\Program 
Files\apache-tomcat\bin\hs_err_pid1244.mdmp
#
# An error report file with more information is saved as:
# D:\Program Files\apache-tomcat\bin\hs_err_pid1244.log
#
# If you would like to submit a bug report, please visit:
#   http://www.azul.com/support/
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#


CONFIG INFO

Here’s the server.xml that causes the JVM crash. 


  

  





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

Re: Regarding Tomcat url redirection

[Christopher Schultz]

Lavanya,

On 5/14/24 09:12, lavanya tech wrote:

IMHO removing the port number is always the preferred solution — I never
did it



can we achieve this with tomcat or we need to setup an reverse proxy here.



Your application uses whatever internal URLs it wants. Are you building
those yourself, or are you asking Tomcat for the e.g. hostname, etc.? If
it's Tomcat, this is where the proxyName and proxyPort come in.


  - Yes, I have not built these UrLs before. It’s was working from the very
beginning. As. I mentioned we are not able to reach goal or whatever.

Rather than saying redirection, I would say it’s aliasing.


Please be specific. "Aliasing" (to me) means "the URL does to the right 
place but doesn't change in the browser's URL" and "redirection" (to 
everybody) means "HTTP 301 or 302 response to a new URL".



Instead of moving applications or changing tomcat configuration it’s easier
to achieve with reverse proxy ?

https://example.lbg.com/ to https://server.lbg.com:8443/towl


This will be a nightmare. Do not try to rewrite URLs using a reverse 
proxy. You should redirect users to the right place if necessary. You 
can use a reverse-proxy if you want, but it won't be any less 
complicated than having Tomcat do it.


I think your rewrite.config file just needs a few tweaks:

# Redirect everything that is not server.lbg.com to
# server.lbg.com. Don't worry about /towl yet.
RewriteCond %{HTTP_HOST} !^server\.lbg\.com$
RewriteRule ^/(.*) https://server.lbg.com:8443/$1 [R=301,L]

# Redirect anything that isn't already going to /towl
# to go to /towl
RewriteCond %{REQUEST_URI} !^/towl
RewriteRule ^/(.*) https://server.lbg.com:8443/towl/$1 [R=301,L]

The application should be deployed as towl.war (or towl/ directory). You 
should listen on ports 80, 443, and 8443, and you should always end up 
at the right place. You should have proxyPort="8443" and 
proxyName="server.lbg.com" in your .


You will not need a ROOT context, since the rewrite will take care of 
that for you.


-chris


On Mon, May 13, 2024 at 10:17 PM lavanya tech 
wrote:

Hi Chris,

Sorry, If I did confuse. It’s important that
https://server.lbg.com:8443/towl is always working. Goal is not to
disable /towl, but just redirect or aliasing

https//example.lbg.com/ to https://server.lbg.com:8443/towl




Thanks,
Lavanya

On Monday, May 13, 2024, Christopher Schultz 


wrote:

Lavanya,

On 5/13/24 05:57, lavanya tech wrote:

Somehow made it work now i can only access urls as you mentioned before
https://example.lbg.com and https://server.lbg.com with port 8443 and
with
out

https://example.lbg.com/towl and https://server.lbg.com/towl --> I
have an
error now File not found.

So i think we need to make work https://example.lbg.com/ to
https://server.lbg.com/towl


I'm sorry, I'm still confused as to which way you want things.

Do you want to redirect /towl -> / or do you want to redirect / - > /towl?

Or does it depend upon the hostname? It would really be better if you
could settle on one specific beahvior.

-chris

On Mon, May 13, 2024 at 9:41 AM lavanya tech 

wrote:

Hi Chris,


Where are you defining the RewriteValve itself?

Defined rewritevalve here
 

 
resource="conf/rewrite.config" />

2) reated rewrite.config and added as below under conf/

RewriteCond %{REQUEST_URI} ^/towl/(.*)
RewriteRule ^/towl/(.*) https://example.lbg.com/%1 [R]

3) After renaming towl to ROOT -> /webapps/ROOT/WEB-INF/web.xml ( I
already have this mappings /* in web.xml file)

  
 
   Logging Area
   
   Authentication for registered users.
   
   /*
   /api/v1/search 
   /api/v1/suggest/* 
 
   
   LDAP_USER
   api
   
   

4) Restarted Tomcat, Then I cannot access
https://server.lbg.com:8443/towl
--> Have below error

Message java.nio.file.NoSuchFileException:
/git/apache-tomcat-10.1.11/webapps/towl/WEB-INF/lib/xss-1.0.8.jar

Description The server encountered an unexpected condition that
prevented
it from fulfilling the request.

5) Also https://example.lbg.com doesnot work anymore

Before you do anything with redirecting, can you just make sure you are
only deploying ROOT.war and nothing else?
   How can I do that. I already changed towl.war to ROOT.war

But still both the urls have error as mentioned above.


Si I revereted back the changes.
That's weird. Try stopping, deleting the work/ directory and restarting.
--> I have this wierd behavior for some reason, thoudh index.jsp is
located
no changes were made to file. After deleting cookies url works

where Am I going wrong.

Thanks,
Lavanya


On Fri, May 10, 2024 at 6:50 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

Lavanya,


On 5/10/24 04:37, lavanya tech wrote:

I tried the below and have the issues.

1)proxyPort="443" and proxyName="example.lbg.com" to the connector
2) remanmed towl.war to ROOT.war
3) created 

Re: Regarding Tomcat url redirection

[lavanya tech]

Hi Chris,

>
> IMHO removing the port number is always the preferred solution — I never
> did it
>
>>
>> can we achieve this with tomcat or we need to setup an reverse proxy here.
>>
>
> Your application uses whatever internal URLs it wants. Are you building
> those yourself, or are you asking Tomcat for the e.g. hostname, etc.? If
> it's Tomcat, this is where the proxyName and proxyPort come in.

 - Yes, I have not built these UrLs before. It’s was working from the very
beginning. As. I mentioned we are not able to reach goal or whatever.

Rather than saying redirection, I would say it’s aliasing.
Instead of moving applications or changing tomcat configuration it’s easier
to achieve with reverse proxy ?

https://example.lbg.com/ to https://server.lbg.com:8443/towl

Kindly let me know what’s the best way.

Thanks,
Ammu




>
> -chris
>
> On Mon, May 13, 2024 at 10:17 PM lavanya tech 
> wrote:
>
> Hi Chris,
>
> Sorry, If I did confuse. It’s important that
> https://server.lbg.com:8443/towl is always working. Goal is not to
> disable /towl, but just redirect or aliasing
>
> https//example.lbg.com/ to https://server.lbg.com:8443/towl
>
>
>
>
> Thanks,
> Lavanya
>
> On Monday, May 13, 2024, Christopher Schultz  >
> wrote:
>
> Lavanya,
>
> On 5/13/24 05:57, lavanya tech wrote:
>
> Somehow made it work now i can only access urls as you mentioned before
> https://example.lbg.com and https://server.lbg.com with port 8443 and
> with
> out
>
>https://example.lbg.com/towl and https://server.lbg.com/towl --> I
> have an
> error now File not found.
>
> So i think we need to make work https://example.lbg.com/ to
> https://server.lbg.com/towl
>
>
> I'm sorry, I'm still confused as to which way you want things.
>
> Do you want to redirect /towl -> / or do you want to redirect / - > /towl?
>
> Or does it depend upon the hostname? It would really be better if you
> could settle on one specific beahvior.
>
> -chris
>
> On Mon, May 13, 2024 at 9:41 AM lavanya tech 
>
> wrote:
>
> Hi Chris,
>
>
> Where are you defining the RewriteValve itself?
>
> Defined rewritevalve here
>unpackWARs="true" autoDeploy="true">
>
>  className="org.apache.catalina.valves.rewrite.RewriteValve" />
>resource="conf/rewrite.config" />
>
> 2) reated rewrite.config and added as below under conf/
>
>RewriteCond %{REQUEST_URI} ^/towl/(.*)
>RewriteRule ^/towl/(.*) https://example.lbg.com/%1 [R]
>
> 3) After renaming towl to ROOT -> /webapps/ROOT/WEB-INF/web.xml ( I
> already have this mappings /* in web.xml file)
>
>  
> 
>   Logging Area
>   
>   Authentication for registered users.
>   
>   /*
>   /api/v1/search 
>   /api/v1/suggest/* 
> 
>   
>   LDAP_USER
>   api
>   
>   
>
> 4) Restarted Tomcat, Then I cannot access
> https://server.lbg.com:8443/towl
> --> Have below error
>
> Message java.nio.file.NoSuchFileException:
> /git/apache-tomcat-10.1.11/webapps/towl/WEB-INF/lib/xss-1.0.8.jar
>
> Description The server encountered an unexpected condition that
> prevented
> it from fulfilling the request.
>
> 5) Also https://example.lbg.com doesnot work anymore
>
> Before you do anything with redirecting, can you just make sure you are
> only deploying ROOT.war and nothing else?
>   How can I do that. I already changed towl.war to ROOT.war
>
> But still both the urls have error as mentioned above.
>
>
> Si I revereted back the changes.
> That's weird. Try stopping, deleting the work/ directory and restarting.
> --> I have this wierd behavior for some reason, thoudh index.jsp is
> located
> no changes were made to file. After deleting cookies url works
>
> where Am I going wrong.
>
> Thanks,
> Lavanya
>
>
> On Fri, May 10, 2024 at 6:50 PM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
> Lavanya,
>
>
> On 5/10/24 04:37, lavanya tech wrote:
>
> I tried the below and have the issues.
>
> 1)proxyPort="443" and proxyName="example.lbg.com" to the connector
> 2) remanmed towl.war to ROOT.war
> 3) created rewrite.config and added as below under conf/
>
>
> Where are you defining the RewriteValve itself?
>
> RewriteCond %{REQUEST_URI} ^/towl/(.*)
>
> RewriteRule ^/towl/(.*) https://example.lbg.com/%1 [R]
>
>
> If this is being handled by the ROOT servlet then I think it's right.
>
> 4) added this in web.xml file of /webapps/towl/web.xml/
>
>
>  
>
>
>
>
>
>Restricted Access to
> /towl
>/towl/*
>
>
> No, this is wrong. Since this is the "towl" application and not ROOT,
> you want to map /* and not /towl/* because the application will never
> see the /towl/ as it's an application/context prefix that Tomcat will
> remove.
>
>
>
>
>
>
>
>
> Also I noticed that even if I rename the towl application to ROOT,
> when
>
> i
>
> call the url 

Re: Regarding Tomcat url redirection

[Christopher Schultz]

Lavanya,

On 5/14/24 03:47, lavanya tech wrote:

Hi Chris,

Tried the below steps. I have the redirection working. But the URL is not
in the browser anymore.

1)   
   

2) /conf/Catalina/localhost --> I added the below in rewrite.config

RewriteCond %{HTTP_HOST} ^example\.lbg\.com$
RewriteCond %{REQUEST_URI} !^/towl$
RewriteRule ^/(.*) https://server.lbg.com:8443/towl [R=301,L]


The problem with this is that it can redirect forever.

/towl/foo -> /towl/towl/foo -> /towl/towl/towl/foo and so on.

Your "stop criteria" ( !^/towl$ ) needs to be more like !^/towl/ without 
the $.



Then it redirects from https://example.lbg.com -->
https://server.lbg.com:8443/towl but the application team raised a concern
the

- alias https://example.lbg.com/--> url stays in the browser


IMHO removing the port number is always the preferred solution.

If https://example.lbg.com/ isn't returning a 301 response, then 
something is not quite right with your configuration.



- towl indexer uses the internal address https://
server.lbg.com.8443/towl rsp.
localhost:8443/towl

can we achieve this with tomcat or we need to setup an reverse proxy here.


Your application uses whatever internal URLs it wants. Are you building 
those yourself, or are you asking Tomcat for the e.g. hostname, etc.? If 
it's Tomcat, this is where the proxyName and proxyPort come in.


-chris


On Mon, May 13, 2024 at 10:17 PM lavanya tech 
wrote:


Hi Chris,

Sorry, If I did confuse. It’s important that
https://server.lbg.com:8443/towl is always working. Goal is not to
disable /towl, but just redirect or aliasing

https//example.lbg.com/ to https://server.lbg.com:8443/towl




Thanks,
Lavanya

On Monday, May 13, 2024, Christopher Schultz 
wrote:


Lavanya,

On 5/13/24 05:57, lavanya tech wrote:


Somehow made it work now i can only access urls as you mentioned before
https://example.lbg.com and https://server.lbg.com with port 8443 and
with
out

   https://example.lbg.com/towl and https://server.lbg.com/towl --> I
have an
error now File not found.

So i think we need to make work https://example.lbg.com/ to
https://server.lbg.com/towl



I'm sorry, I'm still confused as to which way you want things.

Do you want to redirect /towl -> / or do you want to redirect / - > /towl?

Or does it depend upon the hostname? It would really be better if you
could settle on one specific beahvior.

-chris

On Mon, May 13, 2024 at 9:41 AM lavanya tech 

wrote:

Hi Chris,


Where are you defining the RewriteValve itself?

Defined rewritevalve here



   resource="conf/rewrite.config" />

2) reated rewrite.config and added as below under conf/

   RewriteCond %{REQUEST_URI} ^/towl/(.*)
   RewriteRule ^/towl/(.*) https://example.lbg.com/%1 [R]

3) After renaming towl to ROOT -> /webapps/ROOT/WEB-INF/web.xml ( I
already have this mappings /* in web.xml file)

 

  Logging Area
  
  Authentication for registered users.
  
  /*
  /api/v1/search 
  /api/v1/suggest/* 

  
  LDAP_USER
  api
  
  

4) Restarted Tomcat, Then I cannot access
https://server.lbg.com:8443/towl
--> Have below error

Message java.nio.file.NoSuchFileException:
/git/apache-tomcat-10.1.11/webapps/towl/WEB-INF/lib/xss-1.0.8.jar

Description The server encountered an unexpected condition that
prevented
it from fulfilling the request.

5) Also https://example.lbg.com doesnot work anymore

Before you do anything with redirecting, can you just make sure you are
only deploying ROOT.war and nothing else?
  How can I do that. I already changed towl.war to ROOT.war

But still both the urls have error as mentioned above.


Si I revereted back the changes.
That's weird. Try stopping, deleting the work/ directory and restarting.
--> I have this wierd behavior for some reason, thoudh index.jsp is
located
no changes were made to file. After deleting cookies url works

where Am I going wrong.

Thanks,
Lavanya


On Fri, May 10, 2024 at 6:50 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

Lavanya,


On 5/10/24 04:37, lavanya tech wrote:


I tried the below and have the issues.

1)proxyPort="443" and proxyName="example.lbg.com" to the connector
2) remanmed towl.war to ROOT.war
3) created rewrite.config and added as below under conf/



Where are you defining the RewriteValve itself?

RewriteCond %{REQUEST_URI} ^/towl/(.*)

RewriteRule ^/towl/(.*) https://example.lbg.com/%1 [R]



If this is being handled by the ROOT servlet then I think it's right.

4) added this in web.xml file of /webapps/towl/web.xml/


 
   

   
   
   
   Restricted Access to
/towl
   /towl/*



No, this is wrong. Since this is the "towl" application and not ROOT,
you want to map /* and not /towl/* because the application will never
see the /towl/ as it's an 

Re: Regarding Tomcat url redirection

[lavanya tech]

Hi Chris,

Tried the below steps. I have the redirection working. But the URL is not
in the browser anymore.

1)   
  

2) /conf/Catalina/localhost --> I added the below in rewrite.config

RewriteCond %{HTTP_HOST} ^example\.lbg\.com$
RewriteCond %{REQUEST_URI} !^/towl$
RewriteRule ^/(.*) https://server.lbg.com:8443/towl [R=301,L]

Then it redirects from https://example.lbg.com -->
https://server.lbg.com:8443/towl but the application team raised a concern
the

   - alias https://example.lbg.com/--> url stays in the browser
   - towl indexer uses the internal address https://
   server.lbg.com.8443/towl rsp.
   localhost:8443/towl

can we achieve this with tomcat or we need to setup an reverse proxy here.
Pleaes kindly suggest

Thanks,
Lavanya



On Mon, May 13, 2024 at 10:17 PM lavanya tech 
wrote:

> Hi Chris,
>
> Sorry, If I did confuse. It’s important that
> https://server.lbg.com:8443/towl is always working. Goal is not to
> disable /towl, but just redirect or aliasing
>
> https//example.lbg.com/ to https://server.lbg.com:8443/towl
>
>
>
>
> Thanks,
> Lavanya
>
> On Monday, May 13, 2024, Christopher Schultz 
> wrote:
>
>> Lavanya,
>>
>> On 5/13/24 05:57, lavanya tech wrote:
>>
>>> Somehow made it work now i can only access urls as you mentioned before
>>> https://example.lbg.com and https://server.lbg.com with port 8443 and
>>> with
>>> out
>>>
>>>   https://example.lbg.com/towl and https://server.lbg.com/towl --> I
>>> have an
>>> error now File not found.
>>>
>>> So i think we need to make work https://example.lbg.com/ to
>>> https://server.lbg.com/towl
>>>
>>
>> I'm sorry, I'm still confused as to which way you want things.
>>
>> Do you want to redirect /towl -> / or do you want to redirect / - > /towl?
>>
>> Or does it depend upon the hostname? It would really be better if you
>> could settle on one specific beahvior.
>>
>> -chris
>>
>> On Mon, May 13, 2024 at 9:41 AM lavanya tech 
>>> wrote:
>>>
>>> Hi Chris,

 Where are you defining the RewriteValve itself?

 Defined rewritevalve here
>>>  unpackWARs="true" autoDeploy="true">

>>> className="org.apache.catalina.valves.rewrite.RewriteValve" />
   resource="conf/rewrite.config" />

 2) reated rewrite.config and added as below under conf/

   RewriteCond %{REQUEST_URI} ^/towl/(.*)
   RewriteRule ^/towl/(.*) https://example.lbg.com/%1 [R]

 3) After renaming towl to ROOT -> /webapps/ROOT/WEB-INF/web.xml ( I
 already have this mappings /* in web.xml file)

 

  Logging Area
  
  Authentication for registered users.
  
  /*
  /api/v1/search 
  /api/v1/suggest/* 

  
  LDAP_USER
  api
  
  

 4) Restarted Tomcat, Then I cannot access
 https://server.lbg.com:8443/towl
 --> Have below error

 Message java.nio.file.NoSuchFileException:
 /git/apache-tomcat-10.1.11/webapps/towl/WEB-INF/lib/xss-1.0.8.jar

 Description The server encountered an unexpected condition that
 prevented
 it from fulfilling the request.

 5) Also https://example.lbg.com doesnot work anymore

 Before you do anything with redirecting, can you just make sure you are
 only deploying ROOT.war and nothing else?
  How can I do that. I already changed towl.war to ROOT.war

 But still both the urls have error as mentioned above.


 Si I revereted back the changes.
 That's weird. Try stopping, deleting the work/ directory and restarting.
 --> I have this wierd behavior for some reason, thoudh index.jsp is
 located
 no changes were made to file. After deleting cookies url works

 where Am I going wrong.

 Thanks,
 Lavanya


 On Fri, May 10, 2024 at 6:50 PM Christopher Schultz <
 ch...@christopherschultz.net> wrote:

 Lavanya,
>
> On 5/10/24 04:37, lavanya tech wrote:
>
>> I tried the below and have the issues.
>>
>> 1)proxyPort="443" and proxyName="example.lbg.com" to the connector
>> 2) remanmed towl.war to ROOT.war
>> 3) created rewrite.config and added as below under conf/
>>
>
> Where are you defining the RewriteValve itself?
>
> RewriteCond %{REQUEST_URI} ^/towl/(.*)
>> RewriteRule ^/towl/(.*) https://example.lbg.com/%1 [R]
>>
>
> If this is being handled by the ROOT servlet then I think it's right.
>
> 4) added this in web.xml file of /webapps/towl/web.xml/
>>
>> 
>>   
>>
>>   
>>   
>>   
>>   Restricted Access to
>> /towl
>>   /towl/*
>>
>
> No, this is wrong. Since this is the "towl" application and not ROOT,
> 

Re: Regarding Tomcat url redirection

[lavanya tech]

Hi Chris,

Sorry, If I did confuse. It’s important that
https://server.lbg.com:8443/towl is always working. Goal is not to disable
/towl, but just redirect or aliasing

https//example.lbg.com/ to https://server.lbg.com:8443/towl




Thanks,
Lavanya

On Monday, May 13, 2024, Christopher Schultz 
wrote:

> Lavanya,
>
> On 5/13/24 05:57, lavanya tech wrote:
>
>> Somehow made it work now i can only access urls as you mentioned before
>> https://example.lbg.com and https://server.lbg.com with port 8443 and
>> with
>> out
>>
>>   https://example.lbg.com/towl and https://server.lbg.com/towl --> I
>> have an
>> error now File not found.
>>
>> So i think we need to make work https://example.lbg.com/ to
>> https://server.lbg.com/towl
>>
>
> I'm sorry, I'm still confused as to which way you want things.
>
> Do you want to redirect /towl -> / or do you want to redirect / - > /towl?
>
> Or does it depend upon the hostname? It would really be better if you
> could settle on one specific beahvior.
>
> -chris
>
> On Mon, May 13, 2024 at 9:41 AM lavanya tech 
>> wrote:
>>
>> Hi Chris,
>>>
>>> Where are you defining the RewriteValve itself?
>>>
>>> Defined rewritevalve here
>>>>>  unpackWARs="true" autoDeploy="true">
>>>
>>>>> className="org.apache.catalina.valves.rewrite.RewriteValve" />
>>>   resource="conf/rewrite.config" />
>>>
>>> 2) reated rewrite.config and added as below under conf/
>>>
>>>   RewriteCond %{REQUEST_URI} ^/towl/(.*)
>>>   RewriteRule ^/towl/(.*) https://example.lbg.com/%1 [R]
>>>
>>> 3) After renaming towl to ROOT -> /webapps/ROOT/WEB-INF/web.xml ( I
>>> already have this mappings /* in web.xml file)
>>>
>>> 
>>>
>>>  Logging Area
>>>  
>>>  Authentication for registered users.
>>>  
>>>  /*
>>>  /api/v1/search 
>>>  /api/v1/suggest/* 
>>>
>>>  
>>>  LDAP_USER
>>>  api
>>>  
>>>  
>>>
>>> 4) Restarted Tomcat, Then I cannot access https://server.lbg.com:8443/to
>>> wl
>>> --> Have below error
>>>
>>> Message java.nio.file.NoSuchFileException:
>>> /git/apache-tomcat-10.1.11/webapps/towl/WEB-INF/lib/xss-1.0.8.jar
>>>
>>> Description The server encountered an unexpected condition that prevented
>>> it from fulfilling the request.
>>>
>>> 5) Also https://example.lbg.com doesnot work anymore
>>>
>>> Before you do anything with redirecting, can you just make sure you are
>>> only deploying ROOT.war and nothing else?
>>>  How can I do that. I already changed towl.war to ROOT.war
>>>
>>> But still both the urls have error as mentioned above.
>>>
>>>
>>> Si I revereted back the changes.
>>> That's weird. Try stopping, deleting the work/ directory and restarting.
>>> --> I have this wierd behavior for some reason, thoudh index.jsp is
>>> located
>>> no changes were made to file. After deleting cookies url works
>>>
>>> where Am I going wrong.
>>>
>>> Thanks,
>>> Lavanya
>>>
>>>
>>> On Fri, May 10, 2024 at 6:50 PM Christopher Schultz <
>>> ch...@christopherschultz.net> wrote:
>>>
>>> Lavanya,

 On 5/10/24 04:37, lavanya tech wrote:

> I tried the below and have the issues.
>
> 1)proxyPort="443" and proxyName="example.lbg.com" to the connector
> 2) remanmed towl.war to ROOT.war
> 3) created rewrite.config and added as below under conf/
>

 Where are you defining the RewriteValve itself?

 RewriteCond %{REQUEST_URI} ^/towl/(.*)
> RewriteRule ^/towl/(.*) https://example.lbg.com/%1 [R]
>

 If this is being handled by the ROOT servlet then I think it's right.

 4) added this in web.xml file of /webapps/towl/web.xml/
>
> 
>   
>
>   
>   
>   
>   Restricted Access to
> /towl
>   /towl/*
>

 No, this is wrong. Since this is the "towl" application and not ROOT,
 you want to map /* and not /towl/* because the application will never
 see the /towl/ as it's an application/context prefix that Tomcat will
 remove.

   
>   
>   
>   
>   
>
> Also I noticed that even if I rename the towl application to ROOT, when
>
 i

> call the url with https://example.lbg.com/towl --> this towl directory
>
 is

> getting created under webapps by default
>

 If webapps/towl is being created, then it's happening for some other
 reason. Do you have anything under conf/Catalina/*/towl.xml which points
 to a WAR file or something? If so, remove that.

 5) Resarted tomcat and I have the below error and all the urls have the
> same issue
>
> Message org.apache.jasper.JasperException:
> java.lang.ClassNotFoundException: org.apache.jsp.index_jsp
>

 That's weird. Try stopping, deleting the work/ directory and restarting.

 

Re: Regarding Tomcat url redirection

[Christopher Schultz]

Lavanya,

On 5/13/24 05:57, lavanya tech wrote:

Somehow made it work now i can only access urls as you mentioned before
https://example.lbg.com and https://server.lbg.com with port 8443 and with
out

  https://example.lbg.com/towl and https://server.lbg.com/towl --> I have an
error now File not found.

So i think we need to make work https://example.lbg.com/ to
https://server.lbg.com/towl


I'm sorry, I'm still confused as to which way you want things.

Do you want to redirect /towl -> / or do you want to redirect / - > /towl?

Or does it depend upon the hostname? It would really be better if you 
could settle on one specific beahvior.


-chris


On Mon, May 13, 2024 at 9:41 AM lavanya tech 
wrote:


Hi Chris,

Where are you defining the RewriteValve itself?

Defined rewritevalve here
   

   
  resource="conf/rewrite.config" />

2) reated rewrite.config and added as below under conf/

  RewriteCond %{REQUEST_URI} ^/towl/(.*)
  RewriteRule ^/towl/(.*) https://example.lbg.com/%1 [R]

3) After renaming towl to ROOT -> /webapps/ROOT/WEB-INF/web.xml ( I
already have this mappings /* in web.xml file)


   
 Logging Area
 
 Authentication for registered users.
 
 /*
 /api/v1/search 
 /api/v1/suggest/* 
   
 
 LDAP_USER
 api
 
 

4) Restarted Tomcat, Then I cannot access https://server.lbg.com:8443/towl
--> Have below error

Message java.nio.file.NoSuchFileException:
/git/apache-tomcat-10.1.11/webapps/towl/WEB-INF/lib/xss-1.0.8.jar

Description The server encountered an unexpected condition that prevented
it from fulfilling the request.

5) Also https://example.lbg.com doesnot work anymore

Before you do anything with redirecting, can you just make sure you are
only deploying ROOT.war and nothing else?
 How can I do that. I already changed towl.war to ROOT.war

But still both the urls have error as mentioned above.


Si I revereted back the changes.
That's weird. Try stopping, deleting the work/ directory and restarting.
--> I have this wierd behavior for some reason, thoudh index.jsp is located
no changes were made to file. After deleting cookies url works

where Am I going wrong.

Thanks,
Lavanya


On Fri, May 10, 2024 at 6:50 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Lavanya,

On 5/10/24 04:37, lavanya tech wrote:

I tried the below and have the issues.

1)proxyPort="443" and proxyName="example.lbg.com" to the connector
2) remanmed towl.war to ROOT.war
3) created rewrite.config and added as below under conf/


Where are you defining the RewriteValve itself?


RewriteCond %{REQUEST_URI} ^/towl/(.*)
RewriteRule ^/towl/(.*) https://example.lbg.com/%1 [R]


If this is being handled by the ROOT servlet then I think it's right.


4) added this in web.xml file of /webapps/towl/web.xml/


  

  
  
  
  Restricted Access to
/towl
  /towl/*


No, this is wrong. Since this is the "towl" application and not ROOT,
you want to map /* and not /towl/* because the application will never
see the /towl/ as it's an application/context prefix that Tomcat will
remove.


  
  
  
  
  

Also I noticed that even if I rename the towl application to ROOT, when

i

call the url with https://example.lbg.com/towl --> this towl directory

is

getting created under webapps by default


If webapps/towl is being created, then it's happening for some other
reason. Do you have anything under conf/Catalina/*/towl.xml which points
to a WAR file or something? If so, remove that.


5) Resarted tomcat and I have the below error and all the urls have the
same issue

Message org.apache.jasper.JasperException:
java.lang.ClassNotFoundException: org.apache.jsp.index_jsp


That's weird. Try stopping, deleting the work/ directory and restarting.


Description The server encountered an unexpected condition that

prevented

it from fulfilling the request.

Exception

org.apache.jasper.JasperException: org.apache.jasper.JasperException:
java.lang.ClassNotFoundException: org.apache.jsp.index_jsp


org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:578)



org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:422)

org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:380)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:328)
jakarta.servlet.http.HttpServlet.service(HttpServlet.java:658)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51)


Before you do anything with redirecting, can you just make sure you are
only deploying ROOT.war and nothing else?

This should allow you to reach the application at both
https://example.lbg.com/ and https://server.lbg.com/ as well as both of
those with port 8443.

Then use the applications and make sure they are working as expected.
Then, we'll add the /towl handling.

Re: Upgrade query

[Christopher Schultz]

Kalaivani,

On 5/13/24 06:13, GANESAN, Kalaivani wrote:

I have a question regarding upgrading to 9.0.86.
The current version is 9.0.8 and needs to be upgraded to 9.0.86.
We have apache tomcat running in our openptk servers.

Do you have any detailed steps on the process?
We have downloaded apache-tomcat-9.0.86.tar.gz.


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

Upgrade query

[GANESAN, Kalaivani]

Hi,

I have a question regarding upgrading to 9.0.86.
The current version is 9.0.8 and needs to be upgraded to 9.0.86.
We have apache tomcat running in our openptk servers.

Do you have any detailed steps on the process?
We have downloaded apache-tomcat-9.0.86.tar.gz.

Thanks,
Kalaivani G



This e-mail is sent by Suncorp Group Limited ABN 66 145 290 124 or one of its 
related entities "Suncorp".
Suncorp may be contacted at Level 23, 80 Ann Street, Brisbane or on 13 11 55 or 
at suncorp.com.au.
Important Notice: This email may contain an individual's personal information 
(including sensitive information). Our handling of this information is subject 
to privacy laws. As an authorised recipient, please ensure that you take 
reasonable steps to protect and ensure the security of the information.
The content of this e-mail is the view of the sender or stated author and does 
not necessarily reflect the view of Suncorp. The content, including 
attachments, is a confidential communication between Suncorp and the intended 
recipient. If you are not the intended recipient, any use, interference with, 
disclosure or copying of this e-mail, including attachments, is unauthorised 
and expressly prohibited. If you have received this e-mail in error please 
contact the sender immediately and delete the e-mail and any attachments from 
your system.
?

Re: Regarding Tomcat url redirection

[lavanya tech]

Hi Chris,

Somehow made it work now i can only access urls as you mentioned before
https://example.lbg.com and https://server.lbg.com with port 8443 and with
out

 https://example.lbg.com/towl and https://server.lbg.com/towl --> I have an
error now File not found.

So i think we need to make work https://example.lbg.com/ to
https://server.lbg.com/towl

Thanks,
Lavanya


On Mon, May 13, 2024 at 9:41 AM lavanya tech 
wrote:

> Hi Chris,
>
> Where are you defining the RewriteValve itself?
>
> Defined rewritevalve here
>unpackWARs="true" autoDeploy="true">
>
>className="org.apache.catalina.valves.rewrite.RewriteValve" />
>  resource="conf/rewrite.config" />
>
> 2) reated rewrite.config and added as below under conf/
>
>  RewriteCond %{REQUEST_URI} ^/towl/(.*)
>  RewriteRule ^/towl/(.*) https://example.lbg.com/%1 [R]
>
> 3) After renaming towl to ROOT -> /webapps/ROOT/WEB-INF/web.xml ( I
> already have this mappings /* in web.xml file)
>
>
>   
> Logging Area
> 
> Authentication for registered users.
> 
> /*
> /api/v1/search 
> /api/v1/suggest/* 
>   
> 
> LDAP_USER
> api
> 
> 
>
> 4) Restarted Tomcat, Then I cannot access https://server.lbg.com:8443/towl
> --> Have below error
>
> Message java.nio.file.NoSuchFileException:
> /git/apache-tomcat-10.1.11/webapps/towl/WEB-INF/lib/xss-1.0.8.jar
>
> Description The server encountered an unexpected condition that prevented
> it from fulfilling the request.
>
> 5) Also https://example.lbg.com doesnot work anymore
>
> Before you do anything with redirecting, can you just make sure you are
> only deploying ROOT.war and nothing else?
> How can I do that. I already changed towl.war to ROOT.war
>
> But still both the urls have error as mentioned above.
>
>
> Si I revereted back the changes.
> That's weird. Try stopping, deleting the work/ directory and restarting.
> --> I have this wierd behavior for some reason, thoudh index.jsp is located
> no changes were made to file. After deleting cookies url works
>
> where Am I going wrong.
>
> Thanks,
> Lavanya
>
>
> On Fri, May 10, 2024 at 6:50 PM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
>> Lavanya,
>>
>> On 5/10/24 04:37, lavanya tech wrote:
>> > I tried the below and have the issues.
>> >
>> > 1)proxyPort="443" and proxyName="example.lbg.com" to the connector
>> > 2) remanmed towl.war to ROOT.war
>> > 3) created rewrite.config and added as below under conf/
>>
>> Where are you defining the RewriteValve itself?
>>
>> > RewriteCond %{REQUEST_URI} ^/towl/(.*)
>> > RewriteRule ^/towl/(.*) https://example.lbg.com/%1 [R]
>>
>> If this is being handled by the ROOT servlet then I think it's right.
>>
>> > 4) added this in web.xml file of /webapps/towl/web.xml/
>> >
>> >
>> >  
>> >
>> >  
>> >  
>> >  
>> >  Restricted Access to
>> > /towl
>> >  /towl/*
>>
>> No, this is wrong. Since this is the "towl" application and not ROOT,
>> you want to map /* and not /towl/* because the application will never
>> see the /towl/ as it's an application/context prefix that Tomcat will
>> remove.
>>
>> >  
>> >  
>> >  
>> >  
>> >  
>> >
>> > Also I noticed that even if I rename the towl application to ROOT, when
>> i
>> > call the url with https://example.lbg.com/towl --> this towl directory
>> is
>> > getting created under webapps by default
>>
>> If webapps/towl is being created, then it's happening for some other
>> reason. Do you have anything under conf/Catalina/*/towl.xml which points
>> to a WAR file or something? If so, remove that.
>>
>> > 5) Resarted tomcat and I have the below error and all the urls have the
>> > same issue
>> >
>> > Message org.apache.jasper.JasperException:
>> > java.lang.ClassNotFoundException: org.apache.jsp.index_jsp
>>
>> That's weird. Try stopping, deleting the work/ directory and restarting.
>>
>> > Description The server encountered an unexpected condition that
>> prevented
>> > it from fulfilling the request.
>> >
>> > Exception
>> >
>> > org.apache.jasper.JasperException: org.apache.jasper.JasperException:
>> > java.lang.ClassNotFoundException: org.apache.jsp.index_jsp
>> >
>> org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:578)
>> >
>> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:422)
>> > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:380)
>> > org.apache.jasper.servlet.JspServlet.service(JspServlet.java:328)
>> > jakarta.servlet.http.HttpServlet.service(HttpServlet.java:658)
>> > org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51)
>>
>> Before you do anything with redirecting, can you just make sure you are
>> only deploying ROOT.war and nothing else?
>>
>> This should allow you to reach the application at both
>> 

Re: Regarding Tomcat url redirection

[lavanya tech]

Hi Chris,

Where are you defining the RewriteValve itself?

Defined rewritevalve here
  

  
 resource="conf/rewrite.config" />

2) reated rewrite.config and added as below under conf/

 RewriteCond %{REQUEST_URI} ^/towl/(.*)
 RewriteRule ^/towl/(.*) https://example.lbg.com/%1 [R]

3) After renaming towl to ROOT -> /webapps/ROOT/WEB-INF/web.xml ( I already
have this mappings /* in web.xml file)

   
  
Logging Area

Authentication for registered users.

/*
/api/v1/search 
/api/v1/suggest/* 
  

LDAP_USER
api



4) Restarted Tomcat, Then I cannot access https://server.lbg.com:8443/towl
--> Have below error

Message java.nio.file.NoSuchFileException:
/git/apache-tomcat-10.1.11/webapps/towl/WEB-INF/lib/xss-1.0.8.jar

Description The server encountered an unexpected condition that prevented
it from fulfilling the request.

5) Also https://example.lbg.com doesnot work anymore

Before you do anything with redirecting, can you just make sure you are
only deploying ROOT.war and nothing else?
How can I do that. I already changed towl.war to ROOT.war

But still both the urls have error as mentioned above.


Si I revereted back the changes.
That's weird. Try stopping, deleting the work/ directory and restarting.
--> I have this wierd behavior for some reason, thoudh index.jsp is located
no changes were made to file. After deleting cookies url works

where Am I going wrong.

Thanks,
Lavanya


On Fri, May 10, 2024 at 6:50 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Lavanya,
>
> On 5/10/24 04:37, lavanya tech wrote:
> > I tried the below and have the issues.
> >
> > 1)proxyPort="443" and proxyName="example.lbg.com" to the connector
> > 2) remanmed towl.war to ROOT.war
> > 3) created rewrite.config and added as below under conf/
>
> Where are you defining the RewriteValve itself?
>
> > RewriteCond %{REQUEST_URI} ^/towl/(.*)
> > RewriteRule ^/towl/(.*) https://example.lbg.com/%1 [R]
>
> If this is being handled by the ROOT servlet then I think it's right.
>
> > 4) added this in web.xml file of /webapps/towl/web.xml/
> >
> >
> >  
> >
> >  
> >  
> >  
> >  Restricted Access to
> > /towl
> >  /towl/*
>
> No, this is wrong. Since this is the "towl" application and not ROOT,
> you want to map /* and not /towl/* because the application will never
> see the /towl/ as it's an application/context prefix that Tomcat will
> remove.
>
> >  
> >  
> >  
> >  
> >  
> >
> > Also I noticed that even if I rename the towl application to ROOT, when i
> > call the url with https://example.lbg.com/towl --> this towl directory
> is
> > getting created under webapps by default
>
> If webapps/towl is being created, then it's happening for some other
> reason. Do you have anything under conf/Catalina/*/towl.xml which points
> to a WAR file or something? If so, remove that.
>
> > 5) Resarted tomcat and I have the below error and all the urls have the
> > same issue
> >
> > Message org.apache.jasper.JasperException:
> > java.lang.ClassNotFoundException: org.apache.jsp.index_jsp
>
> That's weird. Try stopping, deleting the work/ directory and restarting.
>
> > Description The server encountered an unexpected condition that prevented
> > it from fulfilling the request.
> >
> > Exception
> >
> > org.apache.jasper.JasperException: org.apache.jasper.JasperException:
> > java.lang.ClassNotFoundException: org.apache.jsp.index_jsp
> >
> org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:578)
> >
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:422)
> > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:380)
> > org.apache.jasper.servlet.JspServlet.service(JspServlet.java:328)
> > jakarta.servlet.http.HttpServlet.service(HttpServlet.java:658)
> > org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51)
>
> Before you do anything with redirecting, can you just make sure you are
> only deploying ROOT.war and nothing else?
>
> This should allow you to reach the application at both
> https://example.lbg.com/ and https://server.lbg.com/ as well as both of
> those with port 8443.
>
> Then use the applications and make sure they are working as expected.
> Then, we'll add the /towl handling.
>
> -chris
>
> > On Thu, May 9, 2024 at 11:20 PM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> >> Lavanya,
> >>
> >> On 5/9/24 13:48, lavanya tech wrote:
> >>> Thank you so much for your explanation. I will try these options.
> >>>
> >>> Do server and example both resolve to the same IP?
> >>>   -yes
> >>
> >> Good, that significantly reduces the complexity required, since you can
> >> do it will a single process (Tomcat) in a single environment.
> >>
> >>> So I need follow both 4a/b and 5a/b steps here or 

Re: Regarding Tomcat url redirection

[Christopher Schultz]

Lavanya,

On 5/10/24 06:03, lavanya tech wrote:

If we create new java.filter as below then we can redirect the urls  ?

import javax.servlet.*;
import javax.servlet.annotation.WebFilter;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;

@WebFilter("/*")
public class UrlRedirectionFilter implements Filter {

 @Override
 public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain)
 throws IOException, ServletException {
 HttpServletRequest httpRequest = (HttpServletRequest) request;
 HttpServletResponse httpResponse = (HttpServletResponse) response;

 String requestUrl = httpRequest.getRequestURL().toString();

 // Check if the request URL matches the target URL
 if (requestUrl.equals("https://example.lbg.com;)) {
 // Perform redirect to the desired destination URL
 httpResponse.sendRedirect("https://server.lbg.com/towl;);



This is the exact opposite of the stated goal.

You said you wanted server.lbg.com/towl to be redirected to 
example.lbg.com/ but this does the opposite.


I also wouldn't both to check the protocol. Let's save this until after 
the ROOT application is working as expected.


-chris

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

Re: Regarding Tomcat url redirection

[Christopher Schultz]

Lavanya,

On 5/10/24 04:37, lavanya tech wrote:

I tried the below and have the issues.

1)proxyPort="443" and proxyName="example.lbg.com" to the connector
2) remanmed towl.war to ROOT.war
3) created rewrite.config and added as below under conf/


Where are you defining the RewriteValve itself?


RewriteCond %{REQUEST_URI} ^/towl/(.*)
RewriteRule ^/towl/(.*) https://example.lbg.com/%1 [R]


If this is being handled by the ROOT servlet then I think it's right.


4) added this in web.xml file of /webapps/towl/web.xml/

   
 

 
 
 
 Restricted Access to
/towl
 /towl/*


No, this is wrong. Since this is the "towl" application and not ROOT, 
you want to map /* and not /towl/* because the application will never 
see the /towl/ as it's an application/context prefix that Tomcat will 
remove.



 
 
 
 
 

Also I noticed that even if I rename the towl application to ROOT, when i
call the url with https://example.lbg.com/towl --> this towl directory is
getting created under webapps by default


If webapps/towl is being created, then it's happening for some other 
reason. Do you have anything under conf/Catalina/*/towl.xml which points 
to a WAR file or something? If so, remove that.



5) Resarted tomcat and I have the below error and all the urls have the
same issue

Message org.apache.jasper.JasperException:
java.lang.ClassNotFoundException: org.apache.jsp.index_jsp


That's weird. Try stopping, deleting the work/ directory and restarting.


Description The server encountered an unexpected condition that prevented
it from fulfilling the request.

Exception

org.apache.jasper.JasperException: org.apache.jasper.JasperException:
java.lang.ClassNotFoundException: org.apache.jsp.index_jsp
org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:578)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:422)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:380)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:328)
jakarta.servlet.http.HttpServlet.service(HttpServlet.java:658)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51)


Before you do anything with redirecting, can you just make sure you are 
only deploying ROOT.war and nothing else?


This should allow you to reach the application at both 
https://example.lbg.com/ and https://server.lbg.com/ as well as both of 
those with port 8443.


Then use the applications and make sure they are working as expected. 
Then, we'll add the /towl handling.


-chris


On Thu, May 9, 2024 at 11:20 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Lavanya,

On 5/9/24 13:48, lavanya tech wrote:

Thank you so much for your explanation. I will try these options.

Do server and example both resolve to the same IP?
  -yes


Good, that significantly reduces the complexity required, since you can
do it will a single process (Tomcat) in a single environment.


So I need follow both 4a/b and 5a/b steps here or any of them ?

If I setup exactly by using below steps , then I should access both the
urls right ? https://server.lbg.com:8443/towl and

https://example.lbg.com

If you visit either hostname with /towl, you will be redirected to
example.lbg.com/ with no port number. example:8443 will still work and
no redirect will take place... unless you specifically make arrangements
for that. We can do that later if you really want to.

Let's get the other things working, first.

-chris


On Thursday, May 9, 2024, Christopher Schultz <

ch...@christopherschultz.net>

wrote:


Lavanya,

On 5/9/24 02:58, lavanya tech wrote:


Just giving background again of this topic again.

1) The application team who is working they wanted to access the url
https://server.lbg.com:8443/towl —> which should redirect or point to
https://example.lbg.com

Is that a typo? You want specifically https://server.lbg.com/towl and
https://example.lbg.com/ to point to your application?
 — It’s not the Typo the requirements are still the

same.




Okay.

Do server and example both resolve to the same IP?

2) Hence I added firewall rule to redirect port 443 to 8443. And the url

https://example.lbg.com started working but its pointing to
https://server.lbg.com:8443 indeed and not

https://server.lbg.com:8443/to

wl

But then they wanted the point 1 to have it. If I understood

correctly. So

basically to achieve this we wanted a reverse proxy setup ?

I didnot define any additional host in server.xml file on just left to
default to  local host.



Here's what you have to do in order to support this odd configuration.

1. Configure your firewall to route port 443 -> 8443. I suspect this is
already done.

2. Deploy Tomcat on server.lbg.com with a  on port 8443.

This

is the default, so there shouldn't be anything to do. I suspect this is
already done. You should set proxyPort="443" and proxyName="

Re: Regarding Tomcat url redirection

[lavanya tech]

Hi Chris,
If we create new java.filter as below then we can redirect the urls  ?

import javax.servlet.*;
import javax.servlet.annotation.WebFilter;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;

@WebFilter("/*")
public class UrlRedirectionFilter implements Filter {

@Override
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain)
throws IOException, ServletException {
HttpServletRequest httpRequest = (HttpServletRequest) request;
HttpServletResponse httpResponse = (HttpServletResponse) response;

String requestUrl = httpRequest.getRequestURL().toString();

// Check if the request URL matches the target URL
if (requestUrl.equals("https://example.lbg.com;)) {
// Perform redirect to the desired destination URL
httpResponse.sendRedirect("https://server.lbg.com/towl;);
return;
}

// For all other URLs, disable access
httpResponse.sendError(HttpServletResponse.SC_NOT_FOUND);
}

// Other methods of the Filter interface (init(), destroy()) can be
left empty for this example
}

Thanks,
Lavanya

On Fri, May 10, 2024 at 10:37 AM lavanya tech 
wrote:

> Hi Chris,
>
> I tried the below and have the issues.
>
> 1)proxyPort="443" and proxyName="example.lbg.com" to the connector
> 2) remanmed towl.war to ROOT.war
> 3) created rewrite.config and added as below under conf/
>
> RewriteCond %{REQUEST_URI} ^/towl/(.*)
> RewriteRule ^/towl/(.*) https://example.lbg.com/%1 [R]
>
> 4) added this in web.xml file of /webapps/towl/web.xml/
>
>   
> 
>
> 
> 
> 
> Restricted Access to
> /towl
> /towl/*
> 
> 
> 
> 
> 
>
> Also I noticed that even if I rename the towl application to ROOT, when i
> call the url with https://example.lbg.com/towl --> this towl directory is
> getting created under webapps by default
>
> 5) Resarted tomcat and I have the below error and all the urls have the
> same issue
>
> Message org.apache.jasper.JasperException:
> java.lang.ClassNotFoundException: org.apache.jsp.index_jsp
>
> Description The server encountered an unexpected condition that prevented
> it from fulfilling the request.
>
> Exception
>
> org.apache.jasper.JasperException: org.apache.jasper.JasperException:
> java.lang.ClassNotFoundException: org.apache.jsp.index_jsp
>
> org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:578)
>
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:422)
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:380)
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:328)
> jakarta.servlet.http.HttpServlet.service(HttpServlet.java:658)
> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51)
>
> On Thu, May 9, 2024 at 11:20 PM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
>> Lavanya,
>>
>> On 5/9/24 13:48, lavanya tech wrote:
>> > Thank you so much for your explanation. I will try these options.
>> >
>> > Do server and example both resolve to the same IP?
>> >  -yes
>>
>> Good, that significantly reduces the complexity required, since you can
>> do it will a single process (Tomcat) in a single environment.
>>
>> > So I need follow both 4a/b and 5a/b steps here or any of them ?
>> >
>> > If I setup exactly by using below steps , then I should access both the
>> > urls right ? https://server.lbg.com:8443/towl and
>> https://example.lbg.com
>>
>> If you visit either hostname with /towl, you will be redirected to
>> example.lbg.com/ with no port number. example:8443 will still work and
>> no redirect will take place... unless you specifically make arrangements
>> for that. We can do that later if you really want to.
>>
>> Let's get the other things working, first.
>>
>> -chris
>>
>> > On Thursday, May 9, 2024, Christopher Schultz <
>> ch...@christopherschultz.net>
>> > wrote:
>> >
>> >> Lavanya,
>> >>
>> >> On 5/9/24 02:58, lavanya tech wrote:
>> >>
>> >>> Just giving background again of this topic again.
>> >>>
>> >>> 1) The application team who is working they wanted to access the url
>> >>> https://server.lbg.com:8443/towl —> which should redirect or point to
>> >>> https://example.lbg.com
>> >>>
>> >>> Is that a typo? You want specifically https://server.lbg.com/towl and
>> >>> https://example.lbg.com/ to point to your application?
>> >>> — It’s not the Typo the requirements are still the
>> same.
>> >>>
>> >>
>> >> Okay.
>> >>
>> >> Do server and example both resolve to the same IP?
>> >>
>> >> 2) Hence I added firewall rule to redirect port 443 to 8443. And the
>> url
>> >>> https://example.lbg.com started working but its pointing to
>> >>> https://server.lbg.com:8443 indeed and not
>> https://server.lbg.com:8443/to
>> >>> wl
>> >>>
>> >>> But then they 

Re: Regarding Tomcat url redirection

[lavanya tech]

Hi Chris,

I tried the below and have the issues.

1)proxyPort="443" and proxyName="example.lbg.com" to the connector
2) remanmed towl.war to ROOT.war
3) created rewrite.config and added as below under conf/

RewriteCond %{REQUEST_URI} ^/towl/(.*)
RewriteRule ^/towl/(.*) https://example.lbg.com/%1 [R]

4) added this in web.xml file of /webapps/towl/web.xml/

  





Restricted Access to
/towl
/towl/*






Also I noticed that even if I rename the towl application to ROOT, when i
call the url with https://example.lbg.com/towl --> this towl directory is
getting created under webapps by default

5) Resarted tomcat and I have the below error and all the urls have the
same issue

Message org.apache.jasper.JasperException:
java.lang.ClassNotFoundException: org.apache.jsp.index_jsp

Description The server encountered an unexpected condition that prevented
it from fulfilling the request.

Exception

org.apache.jasper.JasperException: org.apache.jasper.JasperException:
java.lang.ClassNotFoundException: org.apache.jsp.index_jsp
org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:578)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:422)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:380)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:328)
jakarta.servlet.http.HttpServlet.service(HttpServlet.java:658)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51)

On Thu, May 9, 2024 at 11:20 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Lavanya,
>
> On 5/9/24 13:48, lavanya tech wrote:
> > Thank you so much for your explanation. I will try these options.
> >
> > Do server and example both resolve to the same IP?
> >  -yes
>
> Good, that significantly reduces the complexity required, since you can
> do it will a single process (Tomcat) in a single environment.
>
> > So I need follow both 4a/b and 5a/b steps here or any of them ?
> >
> > If I setup exactly by using below steps , then I should access both the
> > urls right ? https://server.lbg.com:8443/towl and
> https://example.lbg.com
>
> If you visit either hostname with /towl, you will be redirected to
> example.lbg.com/ with no port number. example:8443 will still work and
> no redirect will take place... unless you specifically make arrangements
> for that. We can do that later if you really want to.
>
> Let's get the other things working, first.
>
> -chris
>
> > On Thursday, May 9, 2024, Christopher Schultz <
> ch...@christopherschultz.net>
> > wrote:
> >
> >> Lavanya,
> >>
> >> On 5/9/24 02:58, lavanya tech wrote:
> >>
> >>> Just giving background again of this topic again.
> >>>
> >>> 1) The application team who is working they wanted to access the url
> >>> https://server.lbg.com:8443/towl —> which should redirect or point to
> >>> https://example.lbg.com
> >>>
> >>> Is that a typo? You want specifically https://server.lbg.com/towl and
> >>> https://example.lbg.com/ to point to your application?
> >>> — It’s not the Typo the requirements are still the
> same.
> >>>
> >>
> >> Okay.
> >>
> >> Do server and example both resolve to the same IP?
> >>
> >> 2) Hence I added firewall rule to redirect port 443 to 8443. And the url
> >>> https://example.lbg.com started working but its pointing to
> >>> https://server.lbg.com:8443 indeed and not
> https://server.lbg.com:8443/to
> >>> wl
> >>>
> >>> But then they wanted the point 1 to have it. If I understood
> correctly. So
> >>> basically to achieve this we wanted a reverse proxy setup ?
> >>>
> >>> I didnot define any additional host in server.xml file on just left to
> >>> default to  local host.
> >>>
> >>
> >> Here's what you have to do in order to support this odd configuration.
> >>
> >> 1. Configure your firewall to route port 443 -> 8443. I suspect this is
> >> already done.
> >>
> >> 2. Deploy Tomcat on server.lbg.com with a  on port 8443.
> This
> >> is the default, so there shouldn't be anything to do. I suspect this is
> >> already done. You should set proxyPort="443" and proxyName="
> >> example.lbg.com" in your . This will ensure that any URLs
> >> generated by Tomcat or your application will point to
> >> https://example.lbg.com/ and not to server.lbg.com or have a port
> number
> >> or whatever.
> >>
> >> 3. Re-name your application directory or WAR file from towl -> ROOT
> (upper
> >> case is important). So if you have tomcat/webapps/towl re-name that to
> >> tomcat/webapps/ROOT or if you have tomcat/webapps/towl.war re-name that
> to
> >> tomcat/webapps/ROOT.war.
> >>
> >> The last thing to do is get /towl to re-direct to /. There are a few
> ways
> >> of doing that.
> >>
> >> 4a. Configure your application (now called ROOT and deployed on / and
> not
> >> /towl anymore) to handle the /towl URL and specifically redirect this
> back
> >> to /. This is oddly specific and has 

Re: Regarding Tomcat url redirection

[Christopher Schultz]

Lavanya,

On 5/9/24 13:48, lavanya tech wrote:

Thank you so much for your explanation. I will try these options.

Do server and example both resolve to the same IP?
 -yes


Good, that significantly reduces the complexity required, since you can 
do it will a single process (Tomcat) in a single environment.



So I need follow both 4a/b and 5a/b steps here or any of them ?

If I setup exactly by using below steps , then I should access both the
urls right ? https://server.lbg.com:8443/towl and https://example.lbg.com


If you visit either hostname with /towl, you will be redirected to 
example.lbg.com/ with no port number. example:8443 will still work and 
no redirect will take place... unless you specifically make arrangements 
for that. We can do that later if you really want to.


Let's get the other things working, first.

-chris


On Thursday, May 9, 2024, Christopher Schultz 
wrote:


Lavanya,

On 5/9/24 02:58, lavanya tech wrote:


Just giving background again of this topic again.

1) The application team who is working they wanted to access the url
https://server.lbg.com:8443/towl —> which should redirect or point to
https://example.lbg.com

Is that a typo? You want specifically https://server.lbg.com/towl and
https://example.lbg.com/ to point to your application?
— It’s not the Typo the requirements are still the same.



Okay.

Do server and example both resolve to the same IP?

2) Hence I added firewall rule to redirect port 443 to 8443. And the url

https://example.lbg.com started working but its pointing to
https://server.lbg.com:8443 indeed and not https://server.lbg.com:8443/to
wl

But then they wanted the point 1 to have it. If I understood correctly. So
basically to achieve this we wanted a reverse proxy setup ?

I didnot define any additional host in server.xml file on just left to
default to  local host.



Here's what you have to do in order to support this odd configuration.

1. Configure your firewall to route port 443 -> 8443. I suspect this is
already done.

2. Deploy Tomcat on server.lbg.com with a  on port 8443. This
is the default, so there shouldn't be anything to do. I suspect this is
already done. You should set proxyPort="443" and proxyName="
example.lbg.com" in your . This will ensure that any URLs
generated by Tomcat or your application will point to
https://example.lbg.com/ and not to server.lbg.com or have a port number
or whatever.

3. Re-name your application directory or WAR file from towl -> ROOT (upper
case is important). So if you have tomcat/webapps/towl re-name that to
tomcat/webapps/ROOT or if you have tomcat/webapps/towl.war re-name that to
tomcat/webapps/ROOT.war.

The last thing to do is get /towl to re-direct to /. There are a few ways
of doing that.

4a. Configure your application (now called ROOT and deployed on / and not
/towl anymore) to handle the /towl URL and specifically redirect this back
to /. This is oddly specific and has the application trying to redirect to
itself which is weird.

4b. Create a new application called towl or towl.war which will be
deployed on /towl and have THAT redirect to /. I think this is cleaner
because you can call the application anything you'd like and it will still
work. You don't have to match URL patterns yourself, you just re-name the
WAR file if you suddenly want to use /towl2 instead of /towl.

There are several ways to redirect.

5a. Use the rewrite valve and map /(*) to (global redirect) /\1. A few
notes: (1) the (*) means "capture this string" and \1 means "put the string
back. This allows you to redirect /towl/foo/bar to /foo/bar instead of
losing the /foo/bar. This syntax may not be perfect, adapt it to your
needs. (2) Remember that the towl application is deployed on /towl so you
don't want to redirect /towl/foo/bar you only want redirect /foo/bar since
the URL will be relative to the current context (/towl). Got that? Finally,
(3) you need to use a global redirect that does *NOT* redirect back to the
/towl application. Normally, if you redirect to /foo you'll get an
application-relative redirect from something like a rewrite
valve/filter/whatever. Take care to redirect relative to the SERVER and not
to the application.

5b. Write your own servlet to do a specific redirect.

I hope that helps,
-chris

On Wednesday, May 8, 2024, Christopher Schultz <

ch...@christopherschultz.net>
wrote:

Lavanya,


On 5/8/24 06:48, lavanya tech wrote:

I figured out how I can it make it work with 443. Now the URls are

working.
I added iptables route 443 to 8443 and it started working.

nslookup example.lbg.com

Non-authoritative answer:
Name:server.lbg.com
Address:  192.168.200.105
Aliases:  example.lbg.com


I have some application towl running with apache tomcat. I have the
below
URLs working.

https://server.lbg.com:8443/towl
https://server.lbg.com
https://example.lbg.com
https://example.lbg.com/towl


Now i wanted to disable the url https://example.lbg.com/towl and
https://server.lbg.com and 

Re: Regarding Tomcat url redirection

[lavanya tech]

Hi Chris,

Thank you so much for your explanation. I will try these options.

Do server and example both resolve to the same IP?
-yes

So I need follow both 4a/b and 5a/b steps here or any of them ?

If I setup exactly by using below steps , then I should access both the
urls right ? https://server.lbg.com:8443/towl and https://example.lbg.com

I will configure and if I face any issues I will write to you.

Thanks,
Lavanya


On Thursday, May 9, 2024, Christopher Schultz 
wrote:

> Lavanya,
>
> On 5/9/24 02:58, lavanya tech wrote:
>
>> Just giving background again of this topic again.
>>
>> 1) The application team who is working they wanted to access the url
>> https://server.lbg.com:8443/towl —> which should redirect or point to
>> https://example.lbg.com
>>
>> Is that a typo? You want specifically https://server.lbg.com/towl and
>> https://example.lbg.com/ to point to your application?
>>— It’s not the Typo the requirements are still the same.
>>
>
> Okay.
>
> Do server and example both resolve to the same IP?
>
> 2) Hence I added firewall rule to redirect port 443 to 8443. And the url
>> https://example.lbg.com started working but its pointing to
>> https://server.lbg.com:8443 indeed and not https://server.lbg.com:8443/to
>> wl
>>
>> But then they wanted the point 1 to have it. If I understood correctly. So
>> basically to achieve this we wanted a reverse proxy setup ?
>>
>> I didnot define any additional host in server.xml file on just left to
>> default to  local host.
>>
>
> Here's what you have to do in order to support this odd configuration.
>
> 1. Configure your firewall to route port 443 -> 8443. I suspect this is
> already done.
>
> 2. Deploy Tomcat on server.lbg.com with a  on port 8443. This
> is the default, so there shouldn't be anything to do. I suspect this is
> already done. You should set proxyPort="443" and proxyName="
> example.lbg.com" in your . This will ensure that any URLs
> generated by Tomcat or your application will point to
> https://example.lbg.com/ and not to server.lbg.com or have a port number
> or whatever.
>
> 3. Re-name your application directory or WAR file from towl -> ROOT (upper
> case is important). So if you have tomcat/webapps/towl re-name that to
> tomcat/webapps/ROOT or if you have tomcat/webapps/towl.war re-name that to
> tomcat/webapps/ROOT.war.
>
> The last thing to do is get /towl to re-direct to /. There are a few ways
> of doing that.
>
> 4a. Configure your application (now called ROOT and deployed on / and not
> /towl anymore) to handle the /towl URL and specifically redirect this back
> to /. This is oddly specific and has the application trying to redirect to
> itself which is weird.
>
> 4b. Create a new application called towl or towl.war which will be
> deployed on /towl and have THAT redirect to /. I think this is cleaner
> because you can call the application anything you'd like and it will still
> work. You don't have to match URL patterns yourself, you just re-name the
> WAR file if you suddenly want to use /towl2 instead of /towl.
>
> There are several ways to redirect.
>
> 5a. Use the rewrite valve and map /(*) to (global redirect) /\1. A few
> notes: (1) the (*) means "capture this string" and \1 means "put the string
> back. This allows you to redirect /towl/foo/bar to /foo/bar instead of
> losing the /foo/bar. This syntax may not be perfect, adapt it to your
> needs. (2) Remember that the towl application is deployed on /towl so you
> don't want to redirect /towl/foo/bar you only want redirect /foo/bar since
> the URL will be relative to the current context (/towl). Got that? Finally,
> (3) you need to use a global redirect that does *NOT* redirect back to the
> /towl application. Normally, if you redirect to /foo you'll get an
> application-relative redirect from something like a rewrite
> valve/filter/whatever. Take care to redirect relative to the SERVER and not
> to the application.
>
> 5b. Write your own servlet to do a specific redirect.
>
> I hope that helps,
> -chris
>
> On Wednesday, May 8, 2024, Christopher Schultz <
>> ch...@christopherschultz.net>
>> wrote:
>>
>> Lavanya,
>>>
>>> On 5/8/24 06:48, lavanya tech wrote:
>>>
>>> I figured out how I can it make it work with 443. Now the URls are
 working.
 I added iptables route 443 to 8443 and it started working.

 nslookup example.lbg.com

 Non-authoritative answer:
 Name:server.lbg.com
 Address:  192.168.200.105
 Aliases:  example.lbg.com


 I have some application towl running with apache tomcat. I have the
 below
 URLs working.

 https://server.lbg.com:8443/towl
 https://server.lbg.com
 https://example.lbg.com
 https://example.lbg.com/towl


 Now i wanted to disable the url https://example.lbg.com/towl and
 https://server.lbg.com and access only the other remaining two.


>>>
>>
>>
>>> I would *highly* recommend that you pick either /towl or / and not try 

Re: FileUpload class not working with Tomcat 10.1

[Christopher Schultz]

Mark and Chuck,

On 5/9/24 09:35, Chuck Caldarale wrote:

You need the web.xml entries because you have extra configuration
items (the  settings) that aren’t part of the
default JSP servlet definition.

+1

If you didn't need to upload files to your JSP, you wouldn't have needed 
any of this in your web.xml file.


It's very weird to do this kind of logic in a JSP. I *highly* recommend 
that you split your JSP into at least two pieces:


1. A servlet that handles the upload, produces no output, and handles 
error conditions gracefully. It then forwards or redirects (as 
appropriate) to the page you want to display post-upload. You will need 
to map this servlet in web.xml, but it's less-stupid than mapping a JSP 
to a servlet-name and then mapping that same servlet-name back to a URL 
pattern which is the same as the JSP's path. I can see why you were 
saying "I have no idea why this is necessary": it seems useless but you 
must attach the file-upload metadata to something, and this is how you 
do it.


Note that you didn't have to do it that way. You could have done this:


  uploadfile
  /schDistImports.jsp
  ...


  uploadfile
  /schDistImports NOTE: no .jsp extension


In your case, the generic name "uploadfile" for a very specific type of 
upload (schDistImports) might be a mistake, since you might want to 
upload all kinds of files, such as 1099 forms or whatnot. One called 
"uploadfile" seems generic when it's not really generic: it's specific 
to that one workflow.


You can use any name you like. You can use any URL pattern you like as 
well, such as /sch/dist/imports. You don't have to be tied to your 
filesystem layout.


2. A page template (JSP is fine) that only generates page content. No 
mapping in web.xml is necessary for this, which is probably what you are 
used to.


-chris

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

Re: Regarding Tomcat url redirection

[Christopher Schultz]

Lavanya,

On 5/9/24 02:58, lavanya tech wrote:

Just giving background again of this topic again.

1) The application team who is working they wanted to access the url
https://server.lbg.com:8443/towl —> which should redirect or point to
https://example.lbg.com

Is that a typo? You want specifically https://server.lbg.com/towl and
https://example.lbg.com/ to point to your application?
   — It’s not the Typo the requirements are still the same.


Okay.

Do server and example both resolve to the same IP?


2) Hence I added firewall rule to redirect port 443 to 8443. And the url
https://example.lbg.com started working but its pointing to
https://server.lbg.com:8443 indeed and not https://server.lbg.com:8443/towl

But then they wanted the point 1 to have it. If I understood correctly. So
basically to achieve this we wanted a reverse proxy setup ?

I didnot define any additional host in server.xml file on just left to
default to  local host.


Here's what you have to do in order to support this odd configuration.

1. Configure your firewall to route port 443 -> 8443. I suspect this is 
already done.


2. Deploy Tomcat on server.lbg.com with a  on port 8443. This 
is the default, so there shouldn't be anything to do. I suspect this is 
already done. You should set proxyPort="443" and 
proxyName="example.lbg.com" in your . This will ensure that 
any URLs generated by Tomcat or your application will point to 
https://example.lbg.com/ and not to server.lbg.com or have a port number 
or whatever.


3. Re-name your application directory or WAR file from towl -> ROOT 
(upper case is important). So if you have tomcat/webapps/towl re-name 
that to tomcat/webapps/ROOT or if you have tomcat/webapps/towl.war 
re-name that to tomcat/webapps/ROOT.war.


The last thing to do is get /towl to re-direct to /. There are a few 
ways of doing that.


4a. Configure your application (now called ROOT and deployed on / and 
not /towl anymore) to handle the /towl URL and specifically redirect 
this back to /. This is oddly specific and has the application trying to 
redirect to itself which is weird.


4b. Create a new application called towl or towl.war which will be 
deployed on /towl and have THAT redirect to /. I think this is cleaner 
because you can call the application anything you'd like and it will 
still work. You don't have to match URL patterns yourself, you just 
re-name the WAR file if you suddenly want to use /towl2 instead of /towl.


There are several ways to redirect.

5a. Use the rewrite valve and map /(*) to (global redirect) /\1. A few 
notes: (1) the (*) means "capture this string" and \1 means "put the 
string back. This allows you to redirect /towl/foo/bar to /foo/bar 
instead of losing the /foo/bar. This syntax may not be perfect, adapt it 
to your needs. (2) Remember that the towl application is deployed on 
/towl so you don't want to redirect /towl/foo/bar you only want redirect 
/foo/bar since the URL will be relative to the current context (/towl). 
Got that? Finally, (3) you need to use a global redirect that does *NOT* 
redirect back to the /towl application. Normally, if you redirect to 
/foo you'll get an application-relative redirect from something like a 
rewrite valve/filter/whatever. Take care to redirect relative to the 
SERVER and not to the application.


5b. Write your own servlet to do a specific redirect.

I hope that helps,
-chris


On Wednesday, May 8, 2024, Christopher Schultz 
wrote:


Lavanya,

On 5/8/24 06:48, lavanya tech wrote:


I figured out how I can it make it work with 443. Now the URls are
working.
I added iptables route 443 to 8443 and it started working.

nslookup example.lbg.com

Non-authoritative answer:
Name:server.lbg.com
Address:  192.168.200.105
Aliases:  example.lbg.com


I have some application towl running with apache tomcat. I have the below
URLs working.

https://server.lbg.com:8443/towl
https://server.lbg.com
https://example.lbg.com
https://example.lbg.com/towl


Now i wanted to disable the url https://example.lbg.com/towl and
https://server.lbg.com and access only the other remaining two.








I would *highly* recommend that you pick either /towl or / and not try to
do both, unless you want to deploy the application twice (which is fine,
just deploy towl.war and ROOT.war as copies of each other). If you try to
re-write /towl to / or / to /towl, you'll find you spend the rest of your
days tracking-down edge-cases and "fixing" them -- likely making things
confusing and, probably, worse.

In the end our goal to makesure that the links are not  always dead as soon

as the towl is moved to a new machine. Can you pelase assit me how to do
that?



The goal should be that "moving" the application only means changing DNS
and everything else works as expected.

If you:

1. Deploy the application with a single context (e.g. /towl, which I
recommend)

2. Re-direct / to /towl (this requires a reverse-proxy or a ROOT
application that does nothing but 

Re: FileUpload class not working with Tomcat 10.1

[Chuck Caldarale]

> On May 9, 2024, at 01:25, Mark Foley  wrote:
> 
>> Does the JSP need to reference the "program" (servlet?) at all? 
> The program, as shown above didn'twork at all until I put that servlet 
> definition on WEB-INF/web.xml, so I suppose the answer is "yes". As to why, I 
> have not a clue.


A reading of the servlet spec might be in order here. Servlets (including JSPs) 
are selected based on the mapping of the  to the .


>> When you make a request, Tomcat determines which servlet in your application 
>> will service the request. If that's a JSP, then the JSP is invoked. A JSP 
>> just compiles to a servlet, just as if you had written a .java file with a 
>> class that "extends HttpServlet" or similar.
>> 
>> It's not clear what "the program" is: JSP or servlet? Or something else? 
> The programs are written in Java/JSP and, yes, Tomcat "compiles" them to 
> .class -- probably servlets.


No probably about it - JSPs are always compiled into servlets. “Program” is too 
generic a term to be used here - you need to be specific with what you’re 
talking about: servlets you coded and compiled, or JSPs that Tomcat turns into 
servlets. It’s hard to figure out exactly what you’re really talking about.


> I think I may have figured this out. Here are my two servlet definitions in 
> WEB-INF/web.xml:
> 
>   
>   uploadfile
>   /schDistImportResults.jsp
>   
>   /tmp
>   20848820
>   418018841
>   1048576
>   
>   
>   
>uploadfile
>   /schDistImportResults.jsp
>   
> 
>   
>   *upload1099*


I presume the asterisks are not actually present in your config.


>   /1099R-Etrans.jsp
>   
>   /tmp
>   20848820
>   418018841
>   1048576
>   
>   
>   
>*upload1099*
>   /1099R-Etrans.jsp
>   
> 
> In the 2nd definition, Taking Chuck's hint, I changed the servlet-name to 
> "upload1099". That seemed to work for the 1099R-Etrans.jsp program, but I 
> haven't been able to test the schDistImportResults.jsp program yet to see if 
> I broke that one. Why these definitions are needed in web.xml and how all 
> that works under the hood is, as Chuck said, "magic”.


It’s not magic at all - it’s how servlet selection works, as defined in the 
servlet spec. The “magic” was your expectation that servlets with the same name 
could co-exist. You need the web.xml entries because you have extra 
configuration items (the  settings) that aren’t part of the 
default JSP servlet definition.

  - Chuck

Re: Regarding Tomcat url redirection

[lavanya tech]

Hi Chris,

Thanks.

Just giving background again of this topic again.

1) The application team who is working they wanted to access the url
https://server.lbg.com:8443/towl —> which should redirect or point to
https://example.lbg.com

Is that a typo? You want specifically https://server.lbg.com/towl and
https://example.lbg.com/ to point to your application?
  — It’s not the Typo the requirements are still the same.

2) Hence I added firewall rule to redirect port 443 to 8443. And the url
https://example.lbg.com started working but its pointing to
https://server.lbg.com:8443 indeed and not https://server.lbg.com:8443/towl

But then they wanted the point 1 to have it. If I understood correctly. So
basically to achieve this we wanted a reverse proxy setup ?

I didnot define any additional host in server.xml file on just left to
default to  local host.



Thanks,
Lavanya



On Wednesday, May 8, 2024, Christopher Schultz 
wrote:

> Lavanya,
>
> On 5/8/24 06:48, lavanya tech wrote:
>
>> I figured out how I can it make it work with 443. Now the URls are
>> working.
>> I added iptables route 443 to 8443 and it started working.
>>
>> nslookup example.lbg.com
>>
>> Non-authoritative answer:
>> Name:server.lbg.com
>> Address:  192.168.200.105
>> Aliases:  example.lbg.com
>>
>>
>> I have some application towl running with apache tomcat. I have the below
>> URLs working.
>>
>> https://server.lbg.com:8443/towl
>> https://server.lbg.com
>> https://example.lbg.com
>> https://example.lbg.com/towl
>>
>>
>> Now i wanted to disable the url https://example.lbg.com/towl and
>> https://server.lbg.com and access only the other remaining two.
>>
>


>
> I would *highly* recommend that you pick either /towl or / and not try to
> do both, unless you want to deploy the application twice (which is fine,
> just deploy towl.war and ROOT.war as copies of each other). If you try to
> re-write /towl to / or / to /towl, you'll find you spend the rest of your
> days tracking-down edge-cases and "fixing" them -- likely making things
> confusing and, probably, worse.
>
> In the end our goal to makesure that the links are not  always dead as soon
>> as the towl is moved to a new machine. Can you pelase assit me how to do
>> that?
>>
>
> The goal should be that "moving" the application only means changing DNS
> and everything else works as expected.
>
> If you:
>
> 1. Deploy the application with a single context (e.g. /towl, which I
> recommend)
>
> 2. Re-direct / to /towl (this requires a reverse-proxy or a ROOT
> application that does nothing but redirect ; my personal preference)
>
> 3. Do not define any  other than "localhost" and make it the
> default. Do not bother with any  elements since they are not
> necessary.
>
> Moving the application should only require that you:
>
> 4. Deploy the same application with the same configuration in the new
> location
>
> 5. Change DNS to point example.lbg.com and server.lbg.com to the new
> location of the service
>
> Hope that helps,
> -chris
>
> On Tue, Apr 30, 2024 at 5:44 PM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
> Lavanya,
>
> On 4/30/24 07:10, lavanya tech wrote:
>
> Can you tell me how to do the below ? How should I setup Tomcat in
> server.xml ?
>
>
> If you want to use port 443 (the default port for HTTPS) then you will
> need to change Tomcat to bind to port 443 (if that's allowed on your OS)
> or arrange to have port 443 routed to port 8443. You may need additional
> configuration in Tomcat (specifically: proxyPort) to avoid having Tomcat
> generate URLs with ":8443" in them.
>
> Looking forward to your reply.
>
>
> If Tomcat is listening on port 8443 then you will need to include that
> in your URL, period. If you want to allow URLs without a port number,
> you will have to arrange to have something listening on port 443.
>
> On Windows, Tomcat can listen directly on port 443. On UNIX and
> UNIX-like systems, you won't be able to do this without running Tomcat
> as root WHICH YOU ABSOLUTELY SHOULD NOT DO.
>
> There are other ways to get port 443 working, but I'll need to know more
> about your environment. The port issue is "easier" than figuring out
> whatever is going on with your DNS, aliases, etc. so I would recommend
> we fix one thing at a time.
>
> -chris
>
> On Mon, Apr 29, 2024 at 2:03 PM lavanya tech 
> wrote:
>
> Hi Chris,
>
> There is no issues with browser, because I tested with different
>
> browsers
>
> and it all works fine. I am sure that there is no issue with the
> certificate.
>Because I was able to establish successful connections with port
>
> 8443, it
>
> just doesnot work with out port
>
>curl  https://example.lbg.com/towl
> curl: (56) Received HTTP code 504 from proxy after CONNECT
> curl: (56) Received HTTP code 504 from proxy after CONNECT
>
>
> If you want to use port 443 (the default port for HTTPS) then you will
> need to change Tomcat to bind to port 443 (if that's allowed on your OS)
> or arrange to have port 

Re: FileUpload class not working with Tomcat 10.1

[Mark Foley]

On 5/7/2024 4:52 PM, Christopher Schultz wrote:

Mark,

On 5/3/24 12:16, Mark Foley wrote:


On 4/23/24 18:44, Chuck Caldarale wrote:


   uploadfile






   uploadfile
/schDistImportResults.jsp


The first servlet is named “uploadfile”.


On Apr 23, 2024, at 12:42, Mark Foley  wrote:

Now I need to add another program to the system that does file 
uploads. I
created another  definition in WEB-INF/web.xml following 
the original:



   uploadfile






   uploadfile
   /1099R-Etrans.jsp


This second servlet is also named “uploadfile”.

That didn't work so well.  Now, any and all programs using the 
fileupload
function launches this 2nd program 1099R-Etrans.jsp.  It appears 
that this

second  definition replaces the first.

You gave them the same names, so the second one wins...

What magic were you expecting to differentiate between the two?

   - Chuck

I can easily change the name of the second servlet, but how would 
the respective jsp programs (schDistImportResults.jsp, 
1099R-Etrans.jsp) specify one or the other? The programs do:

String contentType = request.getContentType();

if (contentType.startsWith("multipart/form-data;"))
{
 Part fileUpload = request.getPart("taxResults");  // for 
schDistImportResults.jsp

// or
 Part fileUpload = request.getPart("vendor1099-MISC"); // for 
1099R-Etrans.jsp


 InputStream inFile = fileUpload.getInputStream();
  :
}

That's it. There is nothing in the program that specifies a servlet 
name. My initial servlet definition (for schDistImportResults.jsp) 
was based on the XML suggestion from Christopher Schultz back in 
November, 2023. Since only the one jsp program was involved, there 
was no discussion of how to specify more than one program in web.xml.


So, I can (and will) give the servlets different names in web.xml, 
but how does the jsp program select the one for its use?


Does the JSP need to reference the "program" (servlet?) at all? 
The program, as shown above didn'twork at all until I put that servlet 
definition on WEB-INF/web.xml, so I suppose the answer is "yes". As to 
why, I have not a clue.


When you make a request, Tomcat determines which servlet in your 
application will service the request. If that's a JSP, then the JSP is 
invoked. A JSP just compiles to a servlet, just as if you had written 
a .java file with a class that "extends HttpServlet" or similar.


It's not clear what "the program" is: JSP or servlet? Or something else? 
The programs are written in Java/JSP and, yes, Tomcat "compiles" them to 
.class -- probably servlets.


It's also not clear how "the program" would or should reference a 
servlet name.


Maybe you can explain (again)?

-chris
I think I may have figured this out. Here are my two servlet definitions 
in WEB-INF/web.xml:


   
   uploadfile
   /schDistImportResults.jsp
   
   /tmp
   20848820
   418018841
   1048576
   
   
   
    uploadfile
   /schDistImportResults.jsp
   

   
   *upload1099*
   /1099R-Etrans.jsp
   
   /tmp
   20848820
   418018841
   1048576
   
   
   
    *upload1099*
   /1099R-Etrans.jsp
   

In the 2nd definition, Taking Chuck's hint, I changed the servlet-name 
to "upload1099". That seemed to work for the 1099R-Etrans.jsp program, 
but I haven't been able to test the schDistImportResults.jsp program yet 
to see if I broke that one. Why these definitions are needed in web.xml 
and how all that works under the hood is, as Chuck said, "magic".

Re: Regarding Tomcat url redirection

[Christopher Schultz]

Lavanya,

On 5/8/24 06:48, lavanya tech wrote:

I figured out how I can it make it work with 443. Now the URls are working.
I added iptables route 443 to 8443 and it started working.

nslookup example.lbg.com

Non-authoritative answer:
Name:server.lbg.com
Address:  192.168.200.105
Aliases:  example.lbg.com


I have some application towl running with apache tomcat. I have the below
URLs working.

https://server.lbg.com:8443/towl
https://server.lbg.com
https://example.lbg.com
https://example.lbg.com/towl


Now i wanted to disable the url https://example.lbg.com/towl and
https://server.lbg.com and access only the other remaining two.


Is that a typo? You want specifically https://server.lbg.com/towl and 
https://example.lbg.com/ to point to your application?


I would *highly* recommend that you pick either /towl or / and not try 
to do both, unless you want to deploy the application twice (which is 
fine, just deploy towl.war and ROOT.war as copies of each other). If you 
try to re-write /towl to / or / to /towl, you'll find you spend the rest 
of your days tracking-down edge-cases and "fixing" them -- likely making 
things confusing and, probably, worse.



In the end our goal to makesure that the links are not  always dead as soon
as the towl is moved to a new machine. Can you pelase assit me how to do
that?


The goal should be that "moving" the application only means changing DNS 
and everything else works as expected.


If you:

1. Deploy the application with a single context (e.g. /towl, which I 
recommend)


2. Re-direct / to /towl (this requires a reverse-proxy or a ROOT 
application that does nothing but redirect ; my personal preference)


3. Do not define any  other than "localhost" and make it the 
default. Do not bother with any  elements since they are not 
necessary.


Moving the application should only require that you:

4. Deploy the same application with the same configuration in the new 
location


5. Change DNS to point example.lbg.com and server.lbg.com to the new 
location of the service


Hope that helps,
-chris


On Tue, Apr 30, 2024 at 5:44 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Lavanya,

On 4/30/24 07:10, lavanya tech wrote:

Can you tell me how to do the below ? How should I setup Tomcat in
server.xml ?


If you want to use port 443 (the default port for HTTPS) then you will
need to change Tomcat to bind to port 443 (if that's allowed on your OS)
or arrange to have port 443 routed to port 8443. You may need additional
configuration in Tomcat (specifically: proxyPort) to avoid having Tomcat
generate URLs with ":8443" in them.

Looking forward to your reply.


If Tomcat is listening on port 8443 then you will need to include that
in your URL, period. If you want to allow URLs without a port number,
you will have to arrange to have something listening on port 443.

On Windows, Tomcat can listen directly on port 443. On UNIX and
UNIX-like systems, you won't be able to do this without running Tomcat
as root WHICH YOU ABSOLUTELY SHOULD NOT DO.

There are other ways to get port 443 working, but I'll need to know more
about your environment. The port issue is "easier" than figuring out
whatever is going on with your DNS, aliases, etc. so I would recommend
we fix one thing at a time.

-chris


On Mon, Apr 29, 2024 at 2:03 PM lavanya tech 
wrote:


Hi Chris,

There is no issues with browser, because I tested with different

browsers

and it all works fine. I am sure that there is no issue with the
certificate.
   Because I was able to establish successful connections with port

8443, it

just doesnot work with out port

   curl  https://example.lbg.com/towl
curl: (56) Received HTTP code 504 from proxy after CONNECT
curl: (56) Received HTTP code 504 from proxy after CONNECT


If you want to use port 443 (the default port for HTTPS) then you will
need to change Tomcat to bind to port 443 (if that's allowed on your OS)
or arrange to have port 443 routed to port 8443. You may need additional
configuration in Tomcat (specifically: proxyPort) to avoid having Tomcat
generate URLs with ":8443" in them.



should i use connect port like the above ?  But you mentioned before we
dont need any configuration changes. Please clarify I am not able to

figure

this out and I have this issue many days pending. How to make it work

with

port 8443 and with out port

Also I wanted to use weburl with alias name permanently instead of the
hostname. How can I achieve both

Thanks,
Lavanya


-->


On Fri, Apr 26, 2024 at 9:28 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Lavanya,

On 4/25/24 07:24, lavanya tech wrote:

Hi Chris,

One question / doubt:

As I mentioned earlier, the below URLS already working in the browser

https://server.lbg.com:8443/towl
https://example.lbg.com:8443/towl -> redirect ( which means when I

hit in

browser) it points to https://server.lbg.com:8443/towl ---> To be

frank,

even I donot need redirect here, not sure why it redirects.

Re: Regarding Tomcat url redirection

[lavanya tech]

Hello Chris,

I figured out how I can it make it work with 443. Now the URls are working.
I added iptables route 443 to 8443 and it started working.

nslookup example.lbg.com

Non-authoritative answer:
Name:server.lbg.com
Address:  192.168.200.105
Aliases:  example.lbg.com


I have some application towl running with apache tomcat. I have the below
URLs working.

https://server.lbg.com:8443/towl
https://server.lbg.com
https://example.lbg.com
https://example.lbg.com/towl


Now i wanted to disable the url https://example.lbg.com/towl and
https://server.lbg.com and access only the other remaining two.

In the end our goal to makesure that the links are not  always dead as soon
as the towl is moved to a new machine. Can you pelase assit me how to do
that ?

Thanks,
Lavanya

On Tue, Apr 30, 2024 at 5:44 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Lavanya,
>
> On 4/30/24 07:10, lavanya tech wrote:
> > Can you tell me how to do the below ? How should I setup Tomcat in
> > server.xml ?
> >
> >
> > If you want to use port 443 (the default port for HTTPS) then you will
> > need to change Tomcat to bind to port 443 (if that's allowed on your OS)
> > or arrange to have port 443 routed to port 8443. You may need additional
> > configuration in Tomcat (specifically: proxyPort) to avoid having Tomcat
> > generate URLs with ":8443" in them.
> >
> > Looking forward to your reply.
>
> If Tomcat is listening on port 8443 then you will need to include that
> in your URL, period. If you want to allow URLs without a port number,
> you will have to arrange to have something listening on port 443.
>
> On Windows, Tomcat can listen directly on port 443. On UNIX and
> UNIX-like systems, you won't be able to do this without running Tomcat
> as root WHICH YOU ABSOLUTELY SHOULD NOT DO.
>
> There are other ways to get port 443 working, but I'll need to know more
> about your environment. The port issue is "easier" than figuring out
> whatever is going on with your DNS, aliases, etc. so I would recommend
> we fix one thing at a time.
>
> -chris
>
> > On Mon, Apr 29, 2024 at 2:03 PM lavanya tech 
> > wrote:
> >
> >> Hi Chris,
> >>
> >> There is no issues with browser, because I tested with different
> browsers
> >> and it all works fine. I am sure that there is no issue with the
> >> certificate.
> >>   Because I was able to establish successful connections with port
> 8443, it
> >> just doesnot work with out port
> >>
> >>   curl  https://example.lbg.com/towl
> >> curl: (56) Received HTTP code 504 from proxy after CONNECT
> >> curl: (56) Received HTTP code 504 from proxy after CONNECT
> >>
> >>
> >> If you want to use port 443 (the default port for HTTPS) then you will
> >> need to change Tomcat to bind to port 443 (if that's allowed on your OS)
> >> or arrange to have port 443 routed to port 8443. You may need additional
> >> configuration in Tomcat (specifically: proxyPort) to avoid having Tomcat
> >> generate URLs with ":8443" in them.
> >>
> >>  >> connectionTimeout="2"
> >> redirectPort="8443"
> >> maxThreads="150"
> >> scheme="https" secure="true" SSLEnabled="true"
> >> keystoreFile="path_to_your_keystore_file"
> >> keystorePass="your_keystore_password"
> >> keystoreType="PKCS12"
> >> clientAuth="false" sslProtocol="TLS"
> >> proxyPort="443"/>
> >>
> >> should i use connect port like the above ?  But you mentioned before we
> >> dont need any configuration changes. Please clarify I am not able to
> figure
> >> this out and I have this issue many days pending. How to make it work
> with
> >> port 8443 and with out port
> >>
> >> Also I wanted to use weburl with alias name permanently instead of the
> >> hostname. How can I achieve both
> >>
> >> Thanks,
> >> Lavanya
> >>
> >>
> >>-->
> >>
> >>
> >> On Fri, Apr 26, 2024 at 9:28 PM Christopher Schultz <
> >> ch...@christopherschultz.net> wrote:
> >>
> >>> Lavanya,
> >>>
> >>> On 4/25/24 07:24, lavanya tech wrote:
>  Hi Chris,
> 
>  One question / doubt:
> 
>  As I mentioned earlier, the below URLS already working in the browser
> > https://server.lbg.com:8443/towl
> > https://example.lbg.com:8443/towl -> redirect ( which means when I
> >>> hit in
>  browser) it points to https://server.lbg.com:8443/towl ---> To be
> >>> frank,
>  even I donot need redirect here, not sure why it redirects.
> 
>  My question is why its working even though SAN is not registered with
> >>> the
>  certificate ? It doesnot even throw warning in the browser.
> >>>
> >>> I'm not sure. Is it possible you have dismissed this error in the past
> >>> and the browser is remembering that? Try this with a different web
> >>> browser or maybe with curl from the command-line to see what happens.
> >>>
>  Why https://server.lbg.com/towl or https://example.lbg.com/towl -->
> >>> How it
>  should work with New SAN certificate 

Re: [EXTERNAL] RE: After Windows Server Restart, tomcat generating New JSESSIONID even with <%@ page session="false" %>

[Christopher Schultz]

Joey,

On 5/7/24 10:50, Joey Cochran wrote:

Coud this be the culprit ?

${CATALINA_BASE}/conf/context.xml

 
 


Possible, but the report was that every single request generates a new 
JSESSIONID, not that every session seems to have expired and needs to be 
re-initialized.


-chris



From: Hamdan Khan 
Sent: Tuesday, May 7, 2024 9:09 AM
To: users@tomcat.apache.org 
Subject: [EXTERNAL] RE: After Windows Server Restart, tomcat generating New JSESSIONID even 
with <%@ page session="false" %>

Thank you Mark,

We have har files when the server is in error state, it shows that the
jsessionid is sent in request.

*Is there a reverse proxy in the mix?*
No. we directly access tomcat.

*Are you using sessions at all*
Yes, we are using the default tomcat session in debugger it says
(org.apache.catalina.session.StandardSessionFacade)

*That is just a single page and any page can potentially trigger session
cre*ation.
It is a multi page application we create and maintain our UserSession
object, which is used to auth on subsequent requests. The application is
working ok on many of our servers,  but starts to generate jsessionid for
every request once the server goes in the problem state.

*It would be interesting to know if you need to clear both of these or
whether clearing just one is sufficient to resolve the issue. That might
narrow down potential root causes.*
I have requested the team to restart without removing work/temp will update
later in the week.

*You could try attaching a profiler and recording object allocations. That
should show you where/how sessions are being created.*
I don't think that is possible for a production server, but if we can get a
clue on how to reproduce this case.

We have a SessionListener, will add logging to it.

thanks,
Hamdan



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

Re: FileUpload class not working with Tomcat 10.1

[Christopher Schultz]

Mark,

On 5/3/24 12:16, Mark Foley wrote:


On 4/23/24 18:44, Chuck Caldarale wrote:


   uploadfile






   uploadfile
   /schDistImportResults.jsp


The first servlet is named “uploadfile”.


On Apr 23, 2024, at 12:42, Mark Foley  wrote:

Now I need to add another program to the system that does file 
uploads. I
created another  definition in WEB-INF/web.xml following the 
original:



   uploadfile






   uploadfile
   /1099R-Etrans.jsp


This second servlet is also named “uploadfile”.

That didn't work so well.  Now, any and all programs using the 
fileupload
function launches this 2nd program 1099R-Etrans.jsp.  It appears that 
this

second  definition replaces the first.

You gave them the same names, so the second one wins...

What magic were you expecting to differentiate between the two?

   - Chuck

I can easily change the name of the second servlet, but how would the 
respective jsp programs (schDistImportResults.jsp, 1099R-Etrans.jsp) 
specify one or the other? The programs do:

String contentType = request.getContentType();

if (contentType.startsWith("multipart/form-data;"))
{
     Part fileUpload = request.getPart("taxResults");  // for 
schDistImportResults.jsp

// or
     Part fileUpload = request.getPart("vendor1099-MISC"); // for 
1099R-Etrans.jsp


     InputStream inFile = fileUpload.getInputStream();
  :
}

That's it. There is nothing in the program that specifies a servlet 
name. My initial servlet definition (for schDistImportResults.jsp) was 
based on the XML suggestion from Christopher Schultz back in November, 
2023. Since only the one jsp program was involved, there was no 
discussion of how to specify more than one program in web.xml.


So, I can (and will) give the servlets different names in web.xml, but 
how does the jsp program select the one for its use?


Does the JSP need to reference the "program" (servlet?) at all? When you 
make a request, Tomcat determines which servlet in your application will 
service the request. If that's a JSP, then the JSP is invoked. A JSP 
just compiles to a servlet, just as if you had written a .java file with 
a class that "extends HttpServlet" or similar.


It's not clear what "the program" is: JSP or servlet? Or something else? 
It's also not clear how "the program" would or should reference a 
servlet name.


Maybe you can explain (again)?

-chris

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