Tomcat 10.x over 9.x

[Sai Charan Teja Pratti]

Hi,

Can you please share the end of lifecycle date for tomcat 9.x.
Also, please share the necessity of upgrading tomcat to 10.1.x from 9.x

Thanks,
Sai

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Tomcat 10.x over 9.x

[i...@flyingfischer.ch]

Hi

https://googlethatforyou.com?q=tomcat%20lifecycle

Result: https://endoflife.date/tomcat

Regarding "necessity of upgrading tomcat to 10.1.x from 9.x":

https://tomcat.apache.org/whichversion.html

Specifically:

 * Apache Tomcat 9.x builds on Tomcat 8.0.x and 8.5.x and implements
   the Servlet 4.0, JSP 2.3, EL 3.0, WebSocket 1.1 and JASPIC 1.1
   specifications *(the versions required by Java EE 8 platform)*.
 * Apache Tomcat 10.0.x builds on Tomcat 9.0.x and implements the
   Servlet 5.0, JSP 3.0, EL 4.0, WebSocket 2.0 and Authentication 2.0
   specifications *(the versions required by Jakarta EE 9 platform)*.


Markus


Am 12.07.24 um 12:35 schrieb Sai Charan Teja Pratti:

Hi,

Can you please share the end of lifecycle date for tomcat 9.x.
Also, please share the necessity of upgrading tomcat to 10.1.x from 9.x

Thanks,
Sai

This electronic communication and the information and any files 
transmitted with it, or attached to it, are confidential and are 
intended solely for the use of the individual or entity to whom it is 
addressed and may contain information that is confidential, legally 
privileged, protected by privacy laws, or otherwise restricted from 
disclosure to anyone else. If you are not the intended recipient or 
the person responsible for delivering the e-mail to the intended 
recipient, you are hereby notified that any use, copying, 
distributing, dissemination, forwarding, printing, or copying of this 
e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, 
and destroy any printed copy of it. 

Re: Tomcat 10.x over 9.x

[Dimitris Soumis]

Hello,

Regarding the end-of-life date for Tomcat 9.0.x, you can find the relevant
information in this link, which contains an email from the mailing list: End
of Lifecycle for Tomcat 9.0.x
.

As for the necessity of upgrading to Tomcat 10.1.x from 9.0.x, please note
that there are no immediate security concerns, as Tomcat 9 continues to
receive all necessary fixes for new CVEs. However, upgrading to Tomcat
10.1.x allows you to take advantage of the latest standards and APIs with
Jakarta EE 10 specification support. This can be beneficial for staying
up-to-date with current technologies and potentially improving performance
and compatibility with other modern applications and frameworks.

Best regards,

Dimitris

On Fri, Jul 12, 2024 at 1:41 PM Sai Charan Teja Pratti
 wrote:

> Hi,
>
> Can you please share the end of lifecycle date for tomcat 9.x.
> Also, please share the necessity of upgrading tomcat to 10.1.x from 9.x
>
> Thanks,
> Sai
>
> This electronic communication and the information and any files
> transmitted with it, or attached to it, are confidential and are intended
> solely for the use of the individual or entity to whom it is addressed and
> may contain information that is confidential, legally privileged, protected
> by privacy laws, or otherwise restricted from disclosure to anyone else. If
> you are not the intended recipient or the person responsible for delivering
> the e-mail to the intended recipient, you are hereby notified that any use,
> copying, distributing, dissemination, forwarding, printing, or copying of
> this e-mail is strictly prohibited. If you received this e-mail in error,
> please return the e-mail to the sender, delete it from your computer, and
> destroy any printed copy of it.

Re: Tomcat 10.x over 9.x

[Rémy Maucherat]

On Fri, Jul 12, 2024 at 1:04 PM Dimitris Soumis  wrote:
>
> Hello,
>
> Regarding the end-of-life date for Tomcat 9.0.x, you can find the relevant
> information in this link, which contains an email from the mailing list: End
> of Lifecycle for Tomcat 9.0.x
> .
>
> As for the necessity of upgrading to Tomcat 10.1.x from 9.0.x, please note
> that there are no immediate security concerns, as Tomcat 9 continues to
> receive all necessary fixes for new CVEs. However, upgrading to Tomcat
> 10.1.x allows you to take advantage of the latest standards and APIs with
> Jakarta EE 10 specification support. This can be beneficial for staying
> up-to-date with current technologies and potentially improving performance
> and compatibility with other modern applications and frameworks.

Most likely some users will never be able to migrate to jakarta.*. We
know it, so the Tomcat 9.x EOL is a long time away. Maybe 10.1 gets
EOLed before since there's no incentive for not EOLing this one
according to the usual schedule.

I just ported the OpenSSL FFM support to 9.0, which was a big missing
feature compared to 10.1 and 11. This sort of porting likely extends
the usefulness of 9.0. Also keeping branches closer helps long term
maintenance.

As for 9.12 (.x is supposed to match the corresponding major version;
since we do not need a .x now, it means it's not going to be .10, and
.11 seems unlikely as well since we are likely ok for the next 2-3
years), the rationale would be:
- Drop the APR connector.
- Bump the base Java version to at least 17 (likely 21 or 25). The
Java 8 release target is a long term problem since it looks like Java
25 will not have it (Java 22 has now started showing removal
warnings). Developers will thus have to use Java 21 to build Tomcat
9.0. The flexibility of Ant seems to allow navigating everything
relatively easily however.
- Bump dependencies. Thankfully no runtime related dependencies that
we cannot maintain ourselves so this is likely not critical.
- Sync APIs with the corresponding .x to ease maintenance. Most likely
this last one would cause issues.

At this point 9.12 does not look inevitable to me. We'll see !

Rémy

> Best regards,
>
> Dimitris
>
> On Fri, Jul 12, 2024 at 1:41 PM Sai Charan Teja Pratti
>  wrote:
>
> > Hi,
> >
> > Can you please share the end of lifecycle date for tomcat 9.x.
> > Also, please share the necessity of upgrading tomcat to 10.1.x from 9.x
> >
> > Thanks,
> > Sai
> >
> > This electronic communication and the information and any files
> > transmitted with it, or attached to it, are confidential and are intended
> > solely for the use of the individual or entity to whom it is addressed and
> > may contain information that is confidential, legally privileged, protected
> > by privacy laws, or otherwise restricted from disclosure to anyone else. If
> > you are not the intended recipient or the person responsible for delivering
> > the e-mail to the intended recipient, you are hereby notified that any use,
> > copying, distributing, dissemination, forwarding, printing, or copying of
> > this e-mail is strictly prohibited. If you received this e-mail in error,
> > please return the e-mail to the sender, delete it from your computer, and
> > destroy any printed copy of it.

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

RE: Reg: tomcat CPU spikes

[Jalaj Asher]

Thank you Chuck and John for the responses.

Just a few points from the things you highlighted and wanted me to check
1. unpackwar is set to true. I checked and was informed that we need that to be 
true for a specific war file.
2. cachingAllowed=false. We keep it as false across the board.

Also the reason I shared 2 different stacks is to highlight that the problem 
does not occur post restart or with any specific part of the application like 
the parser going in a loop but it kicks of at random times impacting multiple 
tomcats. But all having the same stack waiting on archiveresourceset and 
java.util.zip.

I am working on getting both types of stacks to share here as well.

Had a question we just have one war file if unpack war is triggered why should 
it impact loading jars from the entire webapp lib ?

Regards

Jalaj P Asher





-Original Message-
From: Chuck Caldarale 
Sent: Wednesday, July 10, 2024 6:19 PM
To: Tomcat Users List 
Subject: Re: Reg: tomcat CPU spikes

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


> On Jul 10, 2024, at 17:02, Jalaj Asher 
>  wrote:
>
> Sharing another stack to see if this can give any more insights.this thread 
> is the tomcat main thread was loading about 65MB of data.
>
> "main" #1 prio=5 os_prio=0
>   java.lang.Thread.State: RUNNABLE
>  at java.util.zip.ZipFile.getEntry(Native Method)
>  at java.util.zip.ZipFile.getEntry(ZipFile.java:328)
>  - locked <0xa1b04418> (a java.util.jar.JarFile)
>  at java.util.jar.JarFile.getEntry(JarFile.java:253)
>  at java.util.jar.JarFile.getJarEntry(JarFile.java:236)
>  at 
> org.apache.catalina.webresources.AbstractSingleArchiveResourceSet.getArchiveEntry(AbstractSingleArchiveResourceSet.java:97)
>  at 
> org.apache.catalina.webresources.AbstractArchiveResourceSet.getResource(AbstractArchiveResourceSet.java:249)
>  at 
> org.apache.catalina.webresources.StandardRoot.getResourceInternal(StandardRoot.java:272)
>  at 
> org.apache.catalina.webresources.StandardRoot.getResource(StandardRoot.java:213)
>  at 
> org.apache.catalina.webresources.StandardRoot.getClassLoaderResource(StandardRoot.java:220)
>  at 
> org.apache.catalina.loader.WebappClassLoaderBase.findClassInternal(WebappClassLoaderBase.java:2348)
>  at 
> org.apache.catalina.loader.WebappClassLoaderBase.findClass(WebappClassLoaderBase.java:875)
>  at 
> org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1376)
>  - locked <0xf24fc728> (a java.lang.Object)
>  at 
> org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1220)
>  at java.lang.Class.forName0(Native Method)
>  at java.lang.Class.forName(Class.java:348)
>  at 
> com.sun.beans.finder.ClassFinder.findClass(ClassFinder.java:67)
>  at 
> com.sun.beans.finder.ClassFinder.findClass(ClassFinder.java:110)
>  at 
> com.sun.beans.finder.InstanceFinder.instantiate(InstanceFinder.java:93)
>  at 
> com.sun.beans.finder.InstanceFinder.find(InstanceFinder.java:66)
>  at 
> java.beans.Introspector.findExplicitBeanInfo(Introspector.java:448)
>  at java.beans.Introspector.(Introspector.java:398)
>  at java.beans.Introspector.getBeanInfo(Introspector.java:173)
>  at 
> org.springframework.beans.CachedIntrospectionResults.getBeanInfo(CachedIntrospectionResults.java:255)


Is there some configuration setting in Spring that would disable caching? (I’m 
not really knowledgeable about Spring.)

There should be more in the stack trace that would show what’s triggering the 
getBeanInfo() calls. Tomcat won’t be doing the lookup unless something asks for 
it.

  - Chuck


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


CONFIDENTIALITY NOTICE TO RECIPIENT: This transmission contains confidential 
information belonging to the sender that is legally privileged and proprietary 
and may be subject to protection under the law, including the Health Insurance 
Portability and Accountability Act (HIPAA). If you are not the intended 
recipient of this e-mail, you are prohibited from sharing, copying, or 
otherwise using or disclosing its contents. If you have received this e-mail in 
error, please notify the sender immediately by reply e-mail and permanently 
delete this e-mail and any attachments without reading, forwarding or saving 
them. Thank you.

CONFIDENTIALITY NOTICE TO RECIPIENT: This tr

Re: [EXTERNAL EMAIL] Ubuntu Tomcat package maintenance

[Niranjan Rao]

On 7/11/24 13:13, Joel Griffith wrote:
A year and a half ago I had to stop updating Tomcat because a Ubuntu 
packaging bug force-changes file ownership of the Tomcat installation. 
I'm trying to get in touch with the package maintainers to have that 
fixed. `apt-cache show tomcat`

ZjQcmQRYFpfptBannerStart
This Message Is From an Untrusted Sender
You have not previously corresponded with this sender.
ZjQcmQRYFpfptBannerEnd
A year and a half ago I had to stop updating Tomcat because a Ubuntu
packaging bug force-changes file ownership of the Tomcat installation.  I'm
trying to get in touch with the package maintainers to have that fixed.

`apt-cache show tomcat` givesubuntu-devel-disc...@lists.ubuntu.com  as the
maintainers' mailing list.  I tried emailing it, but my posting was blocked
"pending moderator review" since I'm not a member of that list.  That was a
year and a half ago, and I've heard nothing.

I posted a bug under the Tomcat package on Ubuntu's Launchpad bug tracker,
but that has sat similarly ignored for the past year and a half.

Can anyone on this list help me get in touch with the Ubuntu package
maintainers for Tomcat?  Surely there's someone who can get me a degree or
two closer to them.

Thanks,
Joel


Not the answer you are looking for, but from experience of using tomcat 
on Ubuntu. We never bothered with installer package of Ubuntu as we 
found it often conflicted other settings. Our preferred way is to 
download tar.gz files for both JRE and tomcat and just expand it in 
/usr/share directory and adjust path.


Never gave us any trouble.

Regards,

Niranjan
--

Re: Reg: tomcat CPU spikes

[Christopher Schultz]

Jalaj,

On 7/12/24 10:19, Jalaj Asher wrote:

Thank you Chuck and John for the responses.

Just a few points from the things you highlighted and wanted me to check
1. unpackwar is set to true. I checked and was informed that we need
   that to be true for a specific war file.
2. cachingAllowed=false. We keep it as false across the board.


Well... that'll do it. In order to locate resources, Tomcat needs to 
sift through all of those JAR files every time. Scanning ZIP files is 
expensive.


You might want to reconsider this particular setting in your environment.


Also the reason I shared 2 different stacks is to highlight that the
problem does not occur post restart or with any specific part of the
application like the parser going in a loop but it kicks of at random
times impacting multiple tomcats. But all having the same stack
waiting on archiveresourceset and java.util.zip.
My only question would be "why is this only now coming to your 
attention? Things should have been behaving this way .. for a long time.



I am working on getting both types of stacks to share here as well.

Had a question we just have one war file if unpack war is triggered
why should it impact loading jars from the entire webapp lib ?


Because WEB-INF/lib is full of JAR files that need to be scanned every 
tie you try to load ... anything. Since you have disabled caching, it 
has to re-check every file for every resource-load request.


-chris


-Original Message-
From: Chuck Caldarale 
Sent: Wednesday, July 10, 2024 6:19 PM
To: Tomcat Users List 
Subject: Re: Reg: tomcat CPU spikes

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



On Jul 10, 2024, at 17:02, Jalaj Asher  
wrote:

Sharing another stack to see if this can give any more insights.this thread is 
the tomcat main thread was loading about 65MB of data.

"main" #1 prio=5 os_prio=0
   java.lang.Thread.State: RUNNABLE
  at java.util.zip.ZipFile.getEntry(Native Method)
  at java.util.zip.ZipFile.getEntry(ZipFile.java:328)
  - locked <0xa1b04418> (a java.util.jar.JarFile)
  at java.util.jar.JarFile.getEntry(JarFile.java:253)
  at java.util.jar.JarFile.getJarEntry(JarFile.java:236)
  at 
org.apache.catalina.webresources.AbstractSingleArchiveResourceSet.getArchiveEntry(AbstractSingleArchiveResourceSet.java:97)
  at 
org.apache.catalina.webresources.AbstractArchiveResourceSet.getResource(AbstractArchiveResourceSet.java:249)
  at 
org.apache.catalina.webresources.StandardRoot.getResourceInternal(StandardRoot.java:272)
  at 
org.apache.catalina.webresources.StandardRoot.getResource(StandardRoot.java:213)
  at 
org.apache.catalina.webresources.StandardRoot.getClassLoaderResource(StandardRoot.java:220)
  at 
org.apache.catalina.loader.WebappClassLoaderBase.findClassInternal(WebappClassLoaderBase.java:2348)
  at 
org.apache.catalina.loader.WebappClassLoaderBase.findClass(WebappClassLoaderBase.java:875)
  at 
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1376)
  - locked <0xf24fc728> (a java.lang.Object)
  at 
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1220)
  at java.lang.Class.forName0(Native Method)
  at java.lang.Class.forName(Class.java:348)
  at com.sun.beans.finder.ClassFinder.findClass(ClassFinder.java:67)
  at 
com.sun.beans.finder.ClassFinder.findClass(ClassFinder.java:110)
  at 
com.sun.beans.finder.InstanceFinder.instantiate(InstanceFinder.java:93)
  at 
com.sun.beans.finder.InstanceFinder.find(InstanceFinder.java:66)
  at 
java.beans.Introspector.findExplicitBeanInfo(Introspector.java:448)
  at java.beans.Introspector.(Introspector.java:398)
  at java.beans.Introspector.getBeanInfo(Introspector.java:173)
  at 
org.springframework.beans.CachedIntrospectionResults.getBeanInfo(CachedIntrospectionResults.java:255)



Is there some configuration setting in Spring that would disable caching? (I’m 
not really knowledgeable about Spring.)

There should be more in the stack trace that would show what’s triggering the 
getBeanInfo() calls. Tomcat won’t be doing the lookup unless something asks for 
it.

   - Chuck


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


CONFIDENTIALITY NOTICE TO RECIPIENT: This transmission contains confidential 
information belonging to the sender that is legally privileged and p

Re: Ubuntu Tomcat package maintenance

[Christopher Schultz]

Joel,

On 7/11/24 16:13, Joel Griffith wrote:

A year and a half ago I had to stop updating Tomcat because a Ubuntu
packaging bug force-changes file ownership of the Tomcat installation.  I'm
trying to get in touch with the package maintainers to have that fixed.

`apt-cache show tomcat` gives ubuntu-devel-disc...@lists.ubuntu.com as the
maintainers' mailing list.  I tried emailing it, but my posting was blocked
"pending moderator review" since I'm not a member of that list.  That was a
year and a half ago, and I've heard nothing.

I posted a bug under the Tomcat package on Ubuntu's Launchpad bug tracker,
but that has sat similarly ignored for the past year and a half.

Can anyone on this list help me get in touch with the Ubuntu package
maintainers for Tomcat?  Surely there's someone who can get me a degree or
two closer to them.


Do you know if the package you want is actually from Ubuntu or from 
upstream Debian?


-chris

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