Re: JNDI connection pool in Tomcat 10.1

[Mark Thomas]

On 04/09/2024 21:34, charliedidon...@gmail.com wrote:

Hello

Tomcat 10.1, Java 17, MySQL Connector 9.0

Not sure if this is a Tomcat Config issue or Spring MVC 6 issue

I am converting from Spring MVC 4 to 6 and have the following set up in
Tomcat 10.1

  


Context.xml

 
url="jdbc:mysql://192.168.0.28:3306/reference_tables?allowPublicKeyRetrieval

=true&useSSL=false&autoReconnect=true&"/>


That looks reasonable.


Server.xml

   



 

 


This resource link is unnecessary and may be causing problems. Resource 
links are used in context.xml to expose resources defined in server.xml 
to the web application. You have defined the resource directly in the 
web application so there is no need for a resource link.





ResourceLink name="jdbc/CodereaperDB"

 global="jdbc/CodereaperDB"

 auth="Container"

 type="javax.sql.DataSource" />

   



When I deploy my Spring MVC 6 app I get the following in the Tomcat logs



Enable debug logging for the JNDI lookup with:

org.apache.naming.level = ALL

in $CATALINA_BASE/conf/logging.properties

The full path to that DataSource should be:

java:comp/env/jdbc/CodereaperDB


Mark


  


Caused by: javax.naming.NameNotFoundException: Name [jdbc/jdbcCodereaperDB]
is not bound in this Context. Unable to find [jdbc].

 at
org.apache.naming.NamingContext.lookup(NamingContext.java:520)

 at
org.apache.naming.NamingContext.lookup(NamingContext.java:155)

 at
org.apache.naming.SelectorContext.lookup(SelectorContext.java:144)

 at
java.naming/javax.naming.InitialContext.lookup(InitialContext.java:409)

 at
org.springframework.jndi.JndiTemplate.lambda$lookup$0(JndiTemplate.java:157)

 at
org.springframework.jndi.JndiTemplate.execute(JndiTemplate.java:92)

 at
org.springframework.jndi.JndiTemplate.lookup(JndiTemplate.java:157)

 at
org.springframework.jndi.JndiTemplate.lookup(JndiTemplate.java:179)

 at
org.springframework.jndi.JndiLocatorSupport.lookup(JndiLocatorSupport.java:9
6)

 at
org.springframework.jndi.JndiObjectLocator.lookup(JndiObjectLocator.java:114
)

 at
org.springframework.jndi.JndiObjectFactoryBean.lookupWithFallback(JndiObject
FactoryBean.java:239)

 at
org.springframework.jndi.JndiObjectFactoryBean.afterPropertiesSet(JndiObject
FactoryBean.java:225)

 at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1853)

 at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
.initializeBean(AbstractAutowireCapableBeanFactory.java:1802)

 ... 88 more

Related cause:

 org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'dataSource' defined in class path resource
[atlas-dao-context.xml]: Name [jdbc/jdbcCodereaperDB] is not bound in this
Context. Unable to find [jdbc].

  


Should I still be using javax.sql.DataSource or should I use something else
in the Jakarta packages??

My Spring bean is below

 

 



  

  





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

Nothing but 404 errors

[David Rush]

I've been an avid user of "apt install tomcat9" for years on Ubuntu 22.04
and prior with great success, but I've discovered that the package manager
on Ubuntu 24.04 doesn't support tomcat9.

So I'm trying to install it from the core binary D/L from tomcat.apache.org

I want to use distinct CATALINA_HOME and CATALINA_BASE so that I can more
easily upgrade Tomcat without interfering with the configuration and
deployed webapps.
My CATALINA_HOME is /opt/tomcat9/home (which is a symlink to
/opt/tomcat9/apache-tomcat-9.0.93)
My CATALINA_BASE is /var/opt/tomcat9

I have it set up as a systemd service, and Tomcat runs (stopping and
starting with "sudo systemctl start tomcat9.service" and "sudo systemctl
stop tomcat9.service"), but I'm only ever getting 404 errors with the
familiar Tomcat 404 error page with distinctive dark tuquoise trim and it
correctly identifies the version I have just installed, 9.0.93.

I copied the ROOT webapp from my CATALINA_HOME/webapps to my
CATALINA_BASE/webapps, and I see in my /var/opt/tomcat9/logs/catalina.out
that it was found:

Sep 05, 2024 2:18:53 PM org.apache.catalina.startup.HostConfig
deployDirectory
INFO: Deployment of web application directory
[/var/opt/tomcat9/webapps/ROOT] has finished in [251] ms

Same for the examples webapp:

Sep 05, 2024 2:18:53 PM org.apache.catalina.startup.HostConfig
deployDirectory
INFO: Deploying web application directory
[/var/opt/tomcat9/webapps/examples]

I'm seeing nothing but 404 errors in my
/var/opt/tomcat9/logs/localhost_access_log.2024-09-05.txt

Trying http://localhost:8080/ and http://localhost:8080/index.jsp and
http://localhost:8080/examples/ and
http://localhost:8080/examples/index.html I only ever get a 404 error.

I can stop the tomcat9.service and then I get a "Cannot connect" error.  So
I am hitting Tomcat.

I can change the listening port in /var/opt/tomcat9/conf/server.xml which
means I can get 404 errors on that different port (but demonstrates that
it's finding the right server.xml in my CATALINA_BASE).

What dumb mistake am I making?

-- 

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

I'm getting a -1 value for CPU usage when connecting visual VM to my tomcat server.

[Aditya Kumar]

I have enabled JMX in my tomcat server. I use VisualVM to inspect the
tomcat server.

When I look at java.lang->OperatingSystem I'm seeing a -1 value for a few
CPU value readings. This just suddenly happened. I cant think what changes
might have been made, I don't recall any apart from maybe a Windows Update

[image: jmx.png]

The java version is Eclipse Temurin JDK version 17.0.11 build 17
Can anyone explain this or advise on how to debug further?

There was a report here about this issue. I tried going to JDK 18 but this
did not help.
https://bugs.openjdk.org/browse/JDK-8265104

Re: Nothing but 404 errors

[Sebastian Trost]

David,

On 05.09.2024 16:13, David Rush wrote:

My CATALINA_HOME is /opt/tomcat9/home (which is a symlink to
/opt/tomcat9/apache-tomcat-9.0.93)
My CATALINA_BASE is /var/opt/tomcat9
Why are you setting the CATALINA_BASE-variable? If you're running just 
one Tomcat instance, this variable is not needed. Also, you point this 
variable to a different directory?


See 
https://tomcat.apache.org/tomcat-10.1-doc/introduction.html#CATALINA_HOME_and_CATALINA_BASE


Sebastian

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

Re: Nothing but 404 errors

[Darryl Baker]

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

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




On 9/5/24, 9:56 AM, "David Rush" mailto:david.r...@wyo.gov>> wrote:


Sebastian:


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


David


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


> David,
>
> On 05.09.2024 16:13, David Rush wrote:
> > My CATALINA_HOME is /opt/tomcat9/home (which is a symlink to
> > /opt/tomcat9/apache-tomcat-9.0.93)
> > My CATALINA_BASE is /var/opt/tomcat9
> Why are you setting the CATALINA_BASE-variable? If you're running just
> one Tomcat instance, this variable is not needed. Also, you point this
> variable to a different directory?
>
> See
>
> https://urldefense.com/v3/__https://tomcat.apache.org/tomcat-10.1-doc/introduction.html
>  
> *CATALINA_HOME_and_CATALINA_BASE__;Iw!!Dq0X2DkFhyF93HkjWTBQKhk!Rc7C8HkZWIbxfAm38rp_i-EV1fH7v3D-qSOqznnMXuPLPia3Lv6Ln8BmtPmJv0LMLNRTToWFeSGEIMSE9xhvPZvlufqjKXI$
>  
>
> Sebastian
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org 
> 
> For additional commands, e-mail: users-h...@tomcat.apache.org 
> 
>
>


-- 


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

Re: Tomcat takes over 1 minute to stop

[Quoc Nguyen]

Any insights into this issue please, Mr. Shultz?  Anyone?


​Thanks and regards,


Quoc Nguyen

Sr. Software Engineer | Octo an IBM Company

M: 407.404.4912

quoc.ngu...@octo.us

From: Quoc Nguyen 
Sent: Friday, August 30, 2024 1:03 PM
To: Tomcat Users List 
Subject: Re: Tomcat takes over 1 minute to stop

Thank you Mr. Shultz !!!

We've had warnings like the below forever. I can confirm that these have not 
affected stopping in anyway whatsoever.

WARNING [Catalina-utility-11] 
org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web 
application [web app name] appears to have started a thread named [thread name] 
but has failed to stop it. This is very likely to create a memory leak..

We did try to fix this in the form of a context listener servlet to clean up 
these threads during destroying the context process but, again, this has had no 
effects whatsoever.

===

Tomcat9w.exe --> Shutdown tab --> Timeout

From the logs that I sent, I believe that:

Apache Commons Daemon procrun (1.3.4.0 64-bit) --> took this Timeout into 
account

 Apache Commons Daemon procrun (1.4.0.0 64-bit) --> did NOT take this Timeout 
into account




From: Christopher Schultz 
Sent: Thursday, August 29, 2024 5:59 PM
To: users@tomcat.apache.org
Subject: Re: Tomcat takes over 1 minute to stop

Quoc,

On 8/29/24 15:23, Quoc Nguyen wrote:
> Thank you Mr. Thomas !!!
>
> Yes sir !!! I noticed that a clean Tomcat 9.0.93 install (as with other 
> 9.0.9x versions) stops around 1s. I believe that it is so because it has no 
> managed web apps/resources. Just Tomcat itself. I could be wrong.
>
> Yes, I noticed that there are warnings of non-daemon threads that weren't 
> stopped in catalina.log.  I read somewhere that they're just warnings; thus 
> don't affect this process.
>
> There are no requests running at all while stopping Tomcat. Essentially, 
> install/deploy different versions (9.0.89, 9.0.9x) of Tomcat with the same 
> set of non-changing web apps and stop Tomcat via Windows service and record 
> the stop times.
>
> Yes, I took the thread dumps while stopping version 9.0.90. There is a thread 
> "DestroyJavaVM" that, after a few seconds after Tomcat receives the shutdown 
> signal (maybe after it's done stopping its main stuff), was running for 60s.
>
> That said, there're no explanations for what happened:
>
> a) between version 9.0.13 and 9.0.14 with the introduction of "..scheduled 
> executor to the Server..", which has default wait time of 60s and forces a 
> Timeout in Tomcat9w.exe to get Tomcat stop under 60s.
> b) between version 9.0.89 and 9.0.90 after the upgrade of Apache Commons 
> Daemon procrun to version 1.4.0.0, which has a default pause of 60s.
>
> More work/data to confirm: I'm working with Tomcat version 9.0.89 and 9.0.90 
> (where I noticed the change) in two different boxes.
>
> For version 9.0.90 box: started and stopped. Daemon logs below.
>
> Note:
>
> * Apache Commons Daemon procrun (1.4.0.0 64-bit)
> * exactly 60s wait until finished regardless of the Timeout set in 
> Tomcat9w.exe
>
> [2024-08-29 13:41:58] [info]  [13472] Apache Commons Daemon procrun (1.4.0.0 
> 64-bit) started.
> [2024-08-29 13:41:58] [info]  [13472] Running Service 'Tomcat9'...
> [2024-08-29 13:41:58] [info]  [ 9148] Starting service...
> [2024-08-29 13:41:58] [error] [12380] Could not create instance of 
> java/io/FileOutputStream
> [2024-08-29 13:41:59] [info]  [ 9148] Service started in 1636 milliseconds.
> [2024-08-29 13:42:40] [info]  [13472] Service SERVICE_CONTROL_STOP signalled.
> [2024-08-29 13:42:40] [info]  [11996] Stopping service...
> [2024-08-29 13:43:06] [info]  [11996] Service stop thread completed.
> [2024-08-29 13:44:06] [info]  [13472] Run service finished.
> [2024-08-29 13:44:06] [info]  [13472] Apache Commons Daemon procrun finished.
>
>
> For version 9.0.90 box: switched version 9.0.89 of Tomcat9.exe into this box. 
> Started and stopped. Daemon logs below.
>
> Note:
>
> * Apache Commons Daemon procrun (1.3.4.0 64-bit)
> * stop time is definitely less than 60s if the Timeout set in Tomcat9w.exe is 
> less than 60 and ~63s (or 1 min 3 secs as reported)  when set to 0 (out of 
> the box)
> * the last two log lines of "out of the box" don't appear in the log for 
> Timeout being set to 5. Speculation: the process is short-circuited taking 
> into account the set Timeout.
>
> The Timeout was set for 5:
>
> [2024-08-29 14:08:04] [info]  [11012] Apache Commons Daemon procrun (1.3.4.0 
> 64-bit) started.
> [2024-08-29 14:08:04] [info]  [11012] Running Service 'Tomcat9'...
> [2024-08-29 14:08:04] [info]  [14356] Starting service...
> [2024-08-29 14:08:05] [error] [ 6740] Could not create instance of 
> java/io/FileOutputStream
> [2024-08-29 14:08:06] [info]  [14356] Service started in 1648 milliseconds.
> [2024-08-29 14:08:47] [info]  [11012] Service SERVICE_CONTROL_STOP signalled.
> [2024-08-29 14:08:47] [

Re: Nothing but 404 errors

[David Rush]

Doh!  I have resolved it.

When creating my CATALINA_BASE/conf, server.xml was the only file that I
copied into it (in my defense it's the only file explicitly mentioned as
going into the conf directory under the CATALINA_BASE section on running
multiple tomcat instances in the RUNNING.txt file).

Copying EVERYTHING from CATALINA_HOME/conf to CATALINA_BASE/conf resolved
the issue.

David

On Thu, Sep 5, 2024 at 8:54 AM David Rush  wrote:

> Sebastian:
>
> I want to keep HOME and BASE separate so that when a new version of Tomcat
> comes out it's easy to swap the new binary download in at CATALINA_HOME
> without impacting my configuration or webapps in CATALINA_BASE
>
> David
>
> On Thu, Sep 5, 2024 at 8:52 AM Sebastian Trost
>  wrote:
>
>> David,
>>
>> On 05.09.2024 16:13, David Rush wrote:
>> > My CATALINA_HOME is /opt/tomcat9/home (which is a symlink to
>> > /opt/tomcat9/apache-tomcat-9.0.93)
>> > My CATALINA_BASE is /var/opt/tomcat9
>> Why are you setting the CATALINA_BASE-variable? If you're running just
>> one Tomcat instance, this variable is not needed. Also, you point this
>> variable to a different directory?
>>
>> See
>>
>> https://tomcat.apache.org/tomcat-10.1-doc/introduction.html#CATALINA_HOME_and_CATALINA_BASE
>>
>> Sebastian
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>

-- 

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

Re: Nothing but 404 errors

[David Rush]

Darryl:

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

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

David

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

> My method for updating Tomcat is that it lives behind a symbolic link.
> /opt/tomcat/latest points to the version I want to run.
> /opt/tomcat/apache-tomcat-9.0.XX when I want to upgrade I untar the latest
> version, stop the running version, copy over the needed files to the new
> version, repoint the link, and start up the new version. The system control
> file use the symbolic link so needs no changes.
>
> Darryl Baker, GSEC, GCLD (he/him/his)
> Sr. System Administrator
> Distributed Application Platform Services
> Northwestern University
> 4th Floor
> 2020 Ridge Avenue
> Evanston, IL 60208-0801
> darryl.ba...@northwestern.edu 
> (847) 467-6674 
>
>
>
>
> On 9/5/24, 9:56 AM, "David Rush"  david.r...@wyo.gov>> wrote:
>
>
> Sebastian:
>
>
> I want to keep HOME and BASE separate so that when a new version of Tomcat
> comes out it's easy to swap the new binary download in at CATALINA_HOME
> without impacting my configuration or webapps in CATALINA_BASE
>
>
> David
>
>
> On Thu, Sep 5, 2024 at 8:52 AM Sebastian Trost
> mailto:m...@sebastiantrost.de.inva>lid>
> wrote:
>
>
> > David,
> >
> > On 05.09.2024 16:13, David Rush wrote:
> > > My CATALINA_HOME is /opt/tomcat9/home (which is a symlink to
> > > /opt/tomcat9/apache-tomcat-9.0.93)
> > > My CATALINA_BASE is /var/opt/tomcat9
> > Why are you setting the CATALINA_BASE-variable? If you're running just
> > one Tomcat instance, this variable is not needed. Also, you point this
> > variable to a different directory?
> >
> > See
> >
> >
> https://urldefense.com/v3/__https://tomcat.apache.org/tomcat-10.1-doc/introduction.html
> <
> https://urldefense.com/v3/__https://tomcat.apache.org/tomcat-10.1-doc/introduction.html>*CATALINA_HOME_and_CATALINA_BASE__;Iw!!Dq0X2DkFhyF93HkjWTBQKhk!Rc7C8HkZWIbxfAm38rp_i-EV1fH7v3D-qSOqznnMXuPLPia3Lv6Ln8BmtPmJv0LMLNRTToWFeSGEIMSE9xhvPZvlufqjKXI$
>
> >
> > Sebastian
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org  users-unsubscr...@tomcat.apache.org>
> > For additional commands, e-mail: users-h...@tomcat.apache.org  users-h...@tomcat.apache.org>
> >
> >
>
>
> --
>
>
> E-Mail to and from me, in connection with the transaction
> of public
> business, is subject to the Wyoming Public Records
> Act and may be
> disclosed to third parties.
>
>
>
>

-- 

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

Re: Nothing but 404 errors

[Konstantin Kolinko]

чт, 5 сент. 2024 г. в 17:38, David Rush :
> [...]
>
> I copied the ROOT webapp from my CATALINA_HOME/webapps to my
> CATALINA_BASE/webapps, and I see in my /var/opt/tomcat9/logs/catalina.out
> that it was found:
>
> Sep 05, 2024 2:18:53 PM org.apache.catalina.startup.HostConfig
> deployDirectory
> INFO: Deployment of web application directory
> [/var/opt/tomcat9/webapps/ROOT] has finished in [251] ms
>
> Same for the examples webapp:
>
> Sep 05, 2024 2:18:53 PM org.apache.catalina.startup.HostConfig
> deployDirectory
> INFO: Deploying web application directory
> [/var/opt/tomcat9/webapps/examples]
>
> I'm seeing nothing but 404 errors in my
> /var/opt/tomcat9/logs/localhost_access_log.2024-09-05.txt
>
> Trying http://localhost:8080/ and http://localhost:8080/index.jsp and
> http://localhost:8080/examples/ and
> http://localhost:8080/examples/index.html I only ever get a 404 error.
>
> I can stop the tomcat9.service and then I get a "Cannot connect" error.  So
> I am hitting Tomcat.
>
> I can change the listening port in /var/opt/tomcat9/conf/server.xml which
> means I can get 404 errors on that different port (but demonstrates that
> it's finding the right server.xml in my CATALINA_BASE).
>

1) My guess is that your web applications were deployed but failed to start.

You talk about "catalina.out" but it contains only output from "ConsoleHandler".

ConsoleHandler is configured in conf/logging.properties as
.handlers = 1catalina.org.apache.juli.AsyncFileHandler,
java.util.logging.ConsoleHandler

i.e. it is a handler for the "" (root) logger name.

Web application errors are logged via
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].handlers
= 2localhost.org.apache.juli.AsyncFileHandler

and the "2localhost.*" FileHandler writes to "localhost.*.log" file.
Look there for the messages.

BTW,
I suggest reading "Considerations for production usage" on the Logging
page of the docs., and consider disabling either ConsoleHandler (if
you prefer logging into separate files) or all other configured
FileHandlers (if you prefer logging into catalina.out).
https://tomcat.apache.org/tomcat-9.0-doc/logging.html#Considerations_for_production_usage

Also,
2) index.html and index.jsp are served by DefaultServlet and
JspServlet, respectively.

Usually web applications do not configure them explicitly, but inherit
those servlets from the $CATALINA_BASE/conf/web.xml file.

Is that file OK?

If those servlets are not configured then neither static files nor jsp
files can be served by Tomcat.

3) BTW,
The examples web application is protected by a RemoteAddrValve.
(Configured in its META-INF/context.xml file.)

It is good that you are accessing it via "localhost". Otherwise you
would get 403 errors.

Best regards,
Konstantin Kolinko

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

Re: Nothing but 404 errors

[Mark Eggers]

On 9/5/2024 8:40 AM, David Rush wrote:

Darryl:

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

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

David


I tend to set up my Tomcat environments like the following:

/home/tcadmin/Apache/apache-tomcat-9.0.xx
This is the unaltered unpacking of that tar.gz file from tomcat.apache..org

/home/tcadmin/Platforms/serviceName/9.0.xx
This is the location for a particular service's files that are different 
than the stock Tomcat. Things such as altered server.xml, 
tomcat-users.xml, and Tomcat-wide library files go here.


/home/tcadmin/Platforms/serviceName/vhhosts/hostName/webapps
This is the location of a serviceName's virtual host web application 
directory. A particular service can host multiple virtual hosts, so each 
potential virtual host gets its own webapps directory.


To create a service, I use the following structure:

/home/tcadmin/Services/serviceName/CATALINA_HOME
/home/tcadmin/Services/serviceName/CATALINA_BASE

Link CATALINA_HOME to the appropriate 
/home/tcadmin/Apache/apache-tomcat-9.0.xx directory.


Link CATALINA_BASE to the appropriate 
/home/tcadmin/Platforms/serviceName/9.0.xx directory.


server.xml contains a Host node with:

appBase="/home/tcadmin/Platforms/serviceName/vhost/hostName/webapps"

Now to update, all you do is:

1. Unpack a new version of Tomcat in 
/home/tcadmin/Apache/apache-tomcat-9.0.xx

2. Create a new directory i/home/tcadmin/Platforms/serviceName/9.0.xx
3. Copy appropriate files into /home/tcadmin/Platforms/serviceName/9.0.xx
4. Edit the copied files to match the current configuration

Note that the above 4 steps can be done while the environment is 
running. They can also be automated with scripts.


To update, do the following:

1. Shut down the existing Tomcat service
2. Delete the links in /home/tcadmin/Services/serviceName
3. Make new links to the new places created above
4. Start service

Check either /home/tcadmin/Services/serviceName/CATALINA_BASE/logs or
/home/tcadmin/Platforms/serviceName/9.0.xx/logs for issues.

Oh, and on Ubuntu, the following works so that you can create multiple 
Tomcat services:


Environment=CATALINA_HOME=/home/tcadmin/Services/%i/CATALINA_HOME/
Environment=CATALINA_BASE=/home/tcadmin/Services/%i/CATALINA_BASE/
Environment=CATALINA_PID=/var/run/tomcat/%i.pid

Then you can create a template systemd file with a name like 
tomcat-@.service. When you enable the service, use 
tomcat-serviceName.service. That way you can have multiple Tomcat 
services on one platform.


You'll also need to create /var/run/tomcat at boot, since the /var/run 
filesystem is ephemeral.  Something like the following should work:


[Unit]
Description=Create Tomcat PID directory

[Service]
Type=oneshot
RuntimeDirectory=tomcat
User=tcadmin
Group=tcadmin
ExecStart=/bin/true
RemainAfterExit=true

[Install]
WantedBy=multi-user.target

Finally, if you use the Manager application, you'll need to create a 
manager.xml file in every Platform/serviceName/9.0.xx/conf/Catalina/hostName


Change version numbers (9.0.xx) to suit your environment.

The service account (tcadmin) is an unprivileged user account that 
cannot be logged into remotely. You muse log into the remote system, 
then su to that account. I suppose that I could protect it via sudo so 
that sudo -i -u tcadmin would work.


I think that's about it.

. . . just my two cents
/mde/



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


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

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




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


Sebastian:


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


David


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



David,

On 05.09.2024 16:13, David Rush wrote:

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

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

Re: Migration of Spring MVC 4 app to Spring MVC 6

[Konstantin Kolinko]

ср, 4 сент. 2024 г. в 02:33, :
>
> I am migrating a Spring MVC app from 4.x to 6.x so I am going from Tomcat
> 9.1 Java 8 to Tomcat 10.1 Java 17.
>
> I noticed that in the migration steps on the Tomcat site that there is a
> tool to help with the javax to Jakarta package conversions
>
>
>
> I have downloaded the migration tool from Github
> https://github.com/apache/tomcat-jakartaee-migration
>
> I currently have 2 versions of Java on my machine.  Java 8 (Oracle) and Java
> 17 (Open JDK)
>
>
>
> And am trying to build it and am getting the following error in Eclipse when
> running maven verify.
>
> It appears to be using my Java 8 JRE to run the maven build even though I
> have JRE_HOME set to below
>
> JRE_HOME=C:\Program Files\OpenLogic\jdk-17.0.12.7-hotspot
>
> [...]
>
>
> Output from Maven verify is below
>

How do you start Maven?
Is it "mvn verify" in a Windows Console, or in some other way (e.g.
from within an IDE)?

On Windows "mvn" executes "mvn.cmd" batch script, and that script
works with JAVA_HOME (and knows nothing about JRE_HOME).

If you run from within an IDE, the Java Runtime used for Maven is
configured in launch configuration for Maven (within the IDE), and
environment variables do not matter at all.

Best regards,
Konstantin Kolinko

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

Re: Nothing but 404 errors

[Christopher Schultz]

David,

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

Darryl:

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

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


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


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


-chris


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


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

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




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


Sebastian:


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


David


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



David,

On 05.09.2024 16:13, David Rush wrote:

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

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

See



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



Sebastian

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

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






--


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








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

Re: Nothing but 404 errors

[Mark Thomas]

On 05/09/2024 16:24, David Rush wrote:

Doh!  I have resolved it.

When creating my CATALINA_BASE/conf, server.xml was the only file that I
copied into it (in my defense it's the only file explicitly mentioned as
going into the conf directory under the CATALINA_BASE section on running
multiple tomcat instances in the RUNNING.txt file).

Copying EVERYTHING from CATALINA_HOME/conf to CATALINA_BASE/conf resolved
the issue.


No web.xml meant no default servlet and no JSP servlet defined. Hence 
static files and JSPs will have returned 404s.


Mark


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

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

[Tim Zielke]

I was able to narrow down the issue and find a workaround. If anyone has else 
seen this issue, I would be interested in hearing about it.

Here is a recap of the issue.

The Spring Boot app works fine at openjdk 1.8. When the app is moved to openjdk 
17, the app works initially and then usually within a few minutes the web 
browser starts clocking and then times out. The underlying issue has to do with 
TLS session tokens. There appears to be a defect in the web browser (Windows 10 
in this case) TLS code where it starts throwing the following error after the 
first TLS connection closes and it tries to start another TLS connection. 

[13132:2960:0904/130325.068:ERROR:ssl_client_socket_impl.cc(882)] handshake 
failed; returned -1, SSL error code 1, net_error -101

The web browser then never does actually get a ClientHello over to the Apache 
Tomcat server, as it is stuck in hitting those ssl_client_socket errors in the 
attempt to start the TLS handshake.

Adding this JVM argument to the Spring Boot app fixes the issue and the app can 
run fine at openjdk 17.

jdk.tls.server.enableSessionTicketExtension=false

This turns off the TLS session tickets functionality and the issue goes away. I 
don't really need the performance improvement of TLS session tickets, so this 
is a viable workaround for the issue.


-Original Message-
From: Tim Zielke 
Sent: Thursday, August 15, 2024 9:55 AM
To: Tomcat Users List 
Subject: RE: Web browser clocking issue at Apache Tomcat 10.1.20 on Linux

When the web browser clocking issue happens, the web browser will just clock 
when I click on a link in this application and then eventually time out on the 
browser side. The TCP connections mentioned in original posting represent this 
web browser click that clocked and eventually timed out at the browser. The 
Spring Boot trace is showing that the https request are making it to the server 
side socket and nio-exec threads are starting to act on it. There are several 
nio-exec threads doing a read register on the socket (within the same 
millisecond), but then nothing else happens with the socket. There is no 
nio-exec write register or reading/processing https data from the socket. After 
60 seconds, the connections are closed due to the 
server.tomcat.keep-alive-timeout default setting.

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

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

[External]

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



> web browser clocking issues



Can you clarify what you mean by this please.

Mark

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


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

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

[Tim Zielke]

I missed the reply from Chris Schultz and just saw it when I went to the Apache 
Mail Archives.

Yes, by "clocking" I mean the browser throbber just keeps going and going and 
never gets a response. Maybe clocking is a term we just use at our company. It 
means the app is hanging/stalled and not responding.

I also had a typo below about "TLS session tokens". I meant to say "TLS session 
tickets". 

-Original Message-
From: Tim Zielke  
Sent: Thursday, September 5, 2024 3:42 PM
To: Tomcat Users List 
Subject: RE: Web browser clocking issue at Apache Tomcat 10.1.20 on Linux

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

[External]

I was able to narrow down the issue and find a workaround. If anyone has else 
seen this issue, I would be interested in hearing about it.

Here is a recap of the issue.

The Spring Boot app works fine at openjdk 1.8. When the app is moved to openjdk 
17, the app works initially and then usually within a few minutes the web 
browser starts clocking and then times out. The underlying issue has to do with 
TLS session tokens. There appears to be a defect in the web browser (Windows 10 
in this case) TLS code where it starts throwing the following error after the 
first TLS connection closes and it tries to start another TLS connection.

[13132:2960:0904/130325.068:ERROR:ssl_client_socket_impl.cc(882)] handshake 
failed; returned -1, SSL error code 1, net_error -101

The web browser then never does actually get a ClientHello over to the Apache 
Tomcat server, as it is stuck in hitting those ssl_client_socket errors in the 
attempt to start the TLS handshake.

Adding this JVM argument to the Spring Boot app fixes the issue and the app can 
run fine at openjdk 17.

jdk.tls.server.enableSessionTicketExtension=false

This turns off the TLS session tickets functionality and the issue goes away. I 
don't really need the performance improvement of TLS session tickets, so this 
is a viable workaround for the issue.


-Original Message-
From: Tim Zielke
Sent: Thursday, August 15, 2024 9:55 AM
To: Tomcat Users List 
Subject: RE: Web browser clocking issue at Apache Tomcat 10.1.20 on Linux

When the web browser clocking issue happens, the web browser will just clock 
when I click on a link in this application and then eventually time out on the 
browser side. The TCP connections mentioned in original posting represent this 
web browser click that clocked and eventually timed out at the browser. The 
Spring Boot trace is showing that the https request are making it to the server 
side socket and nio-exec threads are starting to act on it. There are several 
nio-exec threads doing a read register on the socket (within the same 
millisecond), but then nothing else happens with the socket. There is no 
nio-exec write register or reading/processing https data from the socket. After 
60 seconds, the connections are closed due to the 
server.tomcat.keep-alive-timeout default setting.

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

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

[External]

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



> web browser clocking issues



Can you clarify what you mean by this please.

Mark

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


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


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