Problems deploying new .war application on Linux

[Scott,Tim]

Hi all,

I’m struggling with this and am obviously not running into the right terms to 
Google.

I’ve put together a new application and got it working nicely through IntelliJ 
with Tomcat 9.0.59 on my PC but as we’re not going to ship my machine (and 
IntelliJ license!), I need it to run elsewhere.

I’ve subsequently found that it runs in the Tomcat on my PC without being 
launched by IntelliJ, so my focus was on what the difference in config might 
be. I’m using Tomcat 9.0.59 on my PC and on the Linux servers I’ve tried this 
on, although they were 9.0.34, 9.0.45, … now they’re 9.0.59.

I’m using Corretto JDK 11.0.14.1 on my PC. My first Linux (RHEL 7) machine was 
using Corretto 11.0.11.9 and is now 11.0.14.10.

I placed the .war file, named ‘sru.war’ into a webapps folders on a stopped 
Windows 2016 Tomcat 9.0.54 / Corretto 11.0.7.10 system and it worked first time 
– even after forgetting to remove the other .war for an older application.

Everything I’ve tried thus far on Linux has resulted in an http/404 (not 
deployed at all!) or http/500 response with:

javax.servlet.ServletException: Servlet.init() for servlet 
[org.oclc.olib.sru.SRUApplication] threw exception
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:541)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
…



Root Cause



java.lang.IllegalStateException: The resource configuration is not modifiable 
in this context.

 
org.glassfish.jersey.server.ResourceConfig$ImmutableState.register(ResourceConfig.java:248)

 
org.glassfish.jersey.server.ResourceConfig$ImmutableState.register(ResourceConfig.java:195)
…

These are paired with other errors:

java.lang.IllegalStateException: No valid CDI implementation found
at 
javax.enterprise.inject.se.SeContainerInitializer.findSeContainerInitializer(SeContainerInitializer.java:106)
at 
javax.enterprise.inject.se.SeContainerInitializer.newInstance(SeContainerInitializer.java:97)
at 
org.glassfish.jersey.inject.cdi.se.CdiSeInjectionManager.completeRegistration(CdiSeInjectionManager.java:239)

The WEB-INF/lib folder contains “cdi-api-2.0.SP1.jar”.

I’ve been going down the rabbit hole of config tweaking by setting up and 
removing  entries in the server.xml and/or context.xml:
   e.g. 

I’ve tried renaming the war file as ‘sru.war’ and placing it in webapps, 
removing other references to ‘sru’ in the configuration.

I think I’ve exhausted all possibilities of there being a duplicate ‘/sru’ 
context somehow, as many discussions indicate could be the cause. I haven’t 
explored the application itself to see if that is causing this problem – as the 
application works in one place with as close a configuration as I can get.

Annoyingly, I only need Linux for development and QA testing. It will be only 
deployed on Windows 2016 in phase 1 (and may never reach phase 2).

Any ideas where I should tweak next?

Thank you,
Tim

In case it helps, my immediate dependencies are summarised below. They mostly 
result from IntelliJ’s “create a new REST project”.

  *   javax.servlet:javax.servlet-api:4.0.1
  *   org.glassfish.jersey.containers:jersey-container-servlet:2.34
  *   org.glassfish.jersey.media:jersey-media-json-jackson:2.34
  *   org.glassfish.jersey.inject:jersey-cdi2-se:2.34
  *   org.glassfish.jersey.bundles:jaxrs-ri:2.13
  *   org.jboss.weld.se:weld-se-core:4.0.3.Final
  *   org.junit.jupiter:junit-jupiter-api:5.8.1
  *   org.junit.jupiter:junit-jupiter-engine:5.8.1
  *   javax.enterprise:cdi-api:2.0.SP1
  *   ch.qos.logback:logback-classic:1.2.10
  *   com.oracle.ojdbc:ojdbc8:19.3.0.0
  *   uk.org.lidalia:jul-to-slf4j-config:1.0.0
  *   org.slf4j:jul-to-slf4j:1.7.36
  *   org.eclipse.persistence:jakarta.persistence:2.2.3

--
Tim Scott
OCLC · Senior Software Engineer / Technical Product Manager

cc: IT file

AW: Problems deploying new .war application on Linux

[Thomas Hoffmann (Speed4Trade GmbH)]

> -Ursprüngliche Nachricht-
> Von: Scott,Tim 
> Gesendet: Montag, 14. März 2022 11:16
> An: Tomcat Users List 
> Betreff: Problems deploying new .war application on Linux
> 
> Hi all,
> 
> I’m struggling with this and am obviously not running into the right terms to
> Google.
> 
> I’ve put together a new application and got it working nicely through IntelliJ
> with Tomcat 9.0.59 on my PC but as we’re not going to ship my machine (and
> IntelliJ license!), I need it to run elsewhere.
> 
> I’ve subsequently found that it runs in the Tomcat on my PC without being
> launched by IntelliJ, so my focus was on what the difference in config might
> be. I’m using Tomcat 9.0.59 on my PC and on the Linux servers I’ve tried this
> on, although they were 9.0.34, 9.0.45, … now they’re 9.0.59.
> 
> I’m using Corretto JDK 11.0.14.1 on my PC. My first Linux (RHEL 7) machine
> was using Corretto 11.0.11.9 and is now 11.0.14.10.
> 
> I placed the .war file, named ‘sru.war’ into a webapps folders on a stopped
> Windows 2016 Tomcat 9.0.54 / Corretto 11.0.7.10 system and it worked first
> time – even after forgetting to remove the other .war for an older
> application.
> 
> Everything I’ve tried thus far on Linux has resulted in an http/404 (not
> deployed at all!) or http/500 response with:
> 
> javax.servlet.ServletException: Servlet.init() for servlet
> [org.oclc.olib.sru.SRUApplication] threw exception
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorB
> ase.java:541)
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:9
> 2)
> …
> 
> 
> 
> Root Cause
> 
> 
> 
> java.lang.IllegalStateException: The resource configuration is not modifiable
> in this context.
> 
> 
> org.glassfish.jersey.server.ResourceConfig$ImmutableState.register(Resour
> ceConfig.java:248)
> 
> 
> org.glassfish.jersey.server.ResourceConfig$ImmutableState.register(Resour
> ceConfig.java:195)
> …
> 
> These are paired with other errors:
> 
> java.lang.IllegalStateException: No valid CDI implementation found
> at
> javax.enterprise.inject.se.SeContainerInitializer.findSeContainerInitializer(Se
> ContainerInitializer.java:106)
> at
> javax.enterprise.inject.se.SeContainerInitializer.newInstance(SeContainerIni
> tializer.java:97)
> at
> org.glassfish.jersey.inject.cdi.se.CdiSeInjectionManager.completeRegistratio
> n(CdiSeInjectionManager.java:239)
> 
> The WEB-INF/lib folder contains “cdi-api-2.0.SP1.jar”.
> 
> I’ve been going down the rabbit hole of config tweaking by setting up and
> removing  entries in the server.xml and/or context.xml:
>e.g. 
> 
> I’ve tried renaming the war file as ‘sru.war’ and placing it in webapps,
> removing other references to ‘sru’ in the configuration.
> 
> I think I’ve exhausted all possibilities of there being a duplicate ‘/sru’ 
> context
> somehow, as many discussions indicate could be the cause. I haven’t
> explored the application itself to see if that is causing this problem – as 
> the
> application works in one place with as close a configuration as I can get.
> 
> Annoyingly, I only need Linux for development and QA testing. It will be only
> deployed on Windows 2016 in phase 1 (and may never reach phase 2).
> 
> Any ideas where I should tweak next?
> 
> Thank you,
> Tim
> 
> In case it helps, my immediate dependencies are summarised below. They
> mostly result from IntelliJ’s “create a new REST project”.
> 
>   *   javax.servlet:javax.servlet-api:4.0.1
>   *   org.glassfish.jersey.containers:jersey-container-servlet:2.34
>   *   org.glassfish.jersey.media:jersey-media-json-jackson:2.34
>   *   org.glassfish.jersey.inject:jersey-cdi2-se:2.34
>   *   org.glassfish.jersey.bundles:jaxrs-ri:2.13
>   *   org.jboss.weld.se:weld-se-core:4.0.3.Final
>   *   org.junit.jupiter:junit-jupiter-api:5.8.1
>   *   org.junit.jupiter:junit-jupiter-engine:5.8.1
>   *   javax.enterprise:cdi-api:2.0.SP1
>   *   ch.qos.logback:logback-classic:1.2.10
>   *   com.oracle.ojdbc:ojdbc8:19.3.0.0
>   *   uk.org.lidalia:jul-to-slf4j-config:1.0.0
>   *   org.slf4j:jul-to-slf4j:1.7.36
>   *   org.eclipse.persistence:jakarta.persistence:2.2.3
> 
> --
> Tim Scott
> OCLC · Senior Software Engineer / Technical Product Manager
> 
> cc: IT file

Hello Scott,

I think it's not related to Tomcat.
CDI is used by your application and provided by some additional jars.

Maybe you can take a look into the war file and check whether the cdi-jar is in 
the right location /WEB-INF/lib
You can also check if the working tomcat has some additional libs under 
Tomcat/lib which are needed by your application.

Another approach is to do remote debugging and step into the class with the 
error 
(javax.enterprise.inject.se.SeContainerInitializer.findSeContainerInitializer)
The CDI implementation is usually located via the ServiceLocator. It checks all 
jars whether any of them offers a proper CDI implementation.
The jars offer this services via files, located at /META-INF/servi

RE: Problems deploying new .war application on Linux

[Scott,Tim]

Hi Thomas,

Thanks for taking the time. I, too, am sure it’s not a Tomcat but a deployment 
issue.

Comparing the lib folder to Tomcat 9.0.59 between Windows and Linux, I see no 
difference in the file names listed and they all have the same md5 checksums.

Looking at my application’s WEB-INF/lib files in the same way, there’s no 
different there either.

> Another approach is to do remote debugging and step into the class with the 
> error 
> (javax.enterprise.inject.se.SeContainerInitializer.findSeContainerInitializer)
I’ll need to work out how to do that and get back to you.

Thanks,
Tim

--
Tim Scott
OCLC · Senior Software Engineer / Technical Product Manager

cc: IT file

OCLC COVID-19 resources: 
oc.lc/covid19-service-info

From: Thomas Hoffmann (Speed4Trade GmbH) 

Sent: Monday, March 14, 2022 12:12 PM
To: Tomcat Users List 
Subject: [External] AW: Problems deploying new .war application on Linux


> -Ursprüngliche Nachricht-
> Von: Scott,Tim mailto:tim.sc...@oclc.org>>
> Gesendet: Montag, 14. März 2022 11:16
> An: Tomcat Users List 
> mailto:users@tomcat.apache.org>>
> Betreff: Problems deploying new .war application on Linux
>
> Hi all,
>
> I’m struggling with this and am obviously not running into the right terms to
> Google.
>
> I’ve put together a new application and got it working nicely through IntelliJ
> with Tomcat 9.0.59 on my PC but as we’re not going to ship my machine (and
> IntelliJ license!), I need it to run elsewhere.
>
> I’ve subsequently found that it runs in the Tomcat on my PC without being
> launched by IntelliJ, so my focus was on what the difference in config might
> be. I’m using Tomcat 9.0.59 on my PC and on the Linux servers I’ve tried this
> on, although they were 9.0.34, 9.0.45, … now they’re 9.0.59.
>
> I’m using Corretto JDK 11.0.14.1 on my PC. My first Linux 
> (RHEL 7) machine
> was using Corretto 11.0.11.9 and is now 
> 11.0.14.10.
>
> I placed the .war file, named ‘sru.war’ into a webapps folders on a stopped
> Windows 2016 Tomcat 9.0.54 / Corretto 11.0.7.10 system and 
> it worked first
> time – even after forgetting to remove the other .war for an older
> application.
>
> Everything I’ve tried thus far on Linux has resulted in an http/404 (not
> deployed at all!) or http/500 response with:
>
> javax.servlet.ServletException: Servlet.init() for servlet
> [org.oclc.olib.sru.SRUApplication] threw exception
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorB
> http://ase.java:541)
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:9
> 2)
> …
>
>
>
> Root Cause
>
>
>
> java.lang.IllegalStateException: The resource configuration is not modifiable
> in this context.
>
>
> org.glassfish.jersey.server.ResourceConfig$ImmutableState.register(Resour
> http://ceConfig.java:248)
>
>
> org.glassfish.jersey.server.ResourceConfig$ImmutableState.register(Resour
> http://ceConfig.java:195)
> …
>
> These are paired with other errors:
>
> java.lang.IllegalStateException: No valid CDI implementation found
> at
> javax.enterprise.inject.se.SeContainerInitializer.findSeContainerInitializer(Se
> http://ContainerInitializer.java:106)
> at
> javax.enterprise.inject.se.SeContainerInitializer.newInstance(SeContainerIni
> http://tializer.java:97)
> at
> org.glassfish.jersey.inject.cdi.se.CdiSeInjectionManager.completeRegistratio
> n(http://CdiSeInjectionManager.java:239)
>
> The WEB-INF/lib folder contains “cdi-api-2.0.SP1.jar”.
>
> I’ve been going down the rabbit hole of config tweaking by setting up and
> removing  entries in the server.xml and/or context.xml:
> e.g. 
>
> I’ve tried renaming the war file as ‘sru.war’ and placing it in webapps,
> removing other references to ‘sru’ in the configuration.
>
> I think I’ve exhausted all possibilities of there being a duplicate ‘/sru’ 
> context
> somehow, as many discussions indicate could be the cause. I haven’t
> explored the application itself to see if that is causing this problem – as 
> the
> application works in one place with as close a configuration as I can get.
>
> Annoyingly, I only need Linux for development and QA testing. It will be only
> deployed on Windows 2016 in phase 1 (and may never reach phase 2).
>
> Any ideas where I should tweak next?
>
> Thank you,
> Tim
>
> In case it helps, my immediate dependencies are summarised below. They
> mostly result from IntelliJ’s “create a new REST project”.
>
> * javax.servlet:javax.servlet-api:4.0.1
> * org.glassfish.jersey.containers:jersey-container-servlet:2.34
> * org.glassfish.jersey.media:jersey-media-json-jackson:2.34
> * org.glassfish.jersey.inject:jersey-cdi2-se:2.34
> * org.glassfish.jersey.bundles:jaxrs-ri:2.13
> * org.jboss.weld.se:weld-se-co

Re: Problems deploying new .war application on Linux

[Greg Huber]

On the sever where did tomcat come from? a rpm?

Maybe as a test, download tomcat from tomcat.apache.org and see if it 
makes a difference.


On 14/03/2022 10:16, Scott,Tim wrote:

Hi all,

I’m struggling with this and am obviously not running into the right terms to 
Google.

I’ve put together a new application and got it working nicely through IntelliJ 
with Tomcat 9.0.59 on my PC but as we’re not going to ship my machine (and 
IntelliJ license!), I need it to run elsewhere.

I’ve subsequently found that it runs in the Tomcat on my PC without being 
launched by IntelliJ, so my focus was on what the difference in config might 
be. I’m using Tomcat 9.0.59 on my PC and on the Linux servers I’ve tried this 
on, although they were 9.0.34, 9.0.45, … now they’re 9.0.59.

I’m using Corretto JDK 11.0.14.1 on my PC. My first Linux (RHEL 7) machine was 
using Corretto 11.0.11.9 and is now 11.0.14.10.

I placed the .war file, named ‘sru.war’ into a webapps folders on a stopped 
Windows 2016 Tomcat 9.0.54 / Corretto 11.0.7.10 system and it worked first time 
– even after forgetting to remove the other .war for an older application.

Everything I’ve tried thus far on Linux has resulted in an http/404 (not 
deployed at all!) or http/500 response with:

javax.servlet.ServletException: Servlet.init() for servlet 
[org.oclc.olib.sru.SRUApplication] threw exception
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:541)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
…



Root Cause



java.lang.IllegalStateException: The resource configuration is not modifiable 
in this context.

  
org.glassfish.jersey.server.ResourceConfig$ImmutableState.register(ResourceConfig.java:248)

  
org.glassfish.jersey.server.ResourceConfig$ImmutableState.register(ResourceConfig.java:195)
…

These are paired with other errors:

java.lang.IllegalStateException: No valid CDI implementation found
 at 
javax.enterprise.inject.se.SeContainerInitializer.findSeContainerInitializer(SeContainerInitializer.java:106)
 at 
javax.enterprise.inject.se.SeContainerInitializer.newInstance(SeContainerInitializer.java:97)
 at 
org.glassfish.jersey.inject.cdi.se.CdiSeInjectionManager.completeRegistration(CdiSeInjectionManager.java:239)

The WEB-INF/lib folder contains “cdi-api-2.0.SP1.jar”.

I’ve been going down the rabbit hole of config tweaking by setting up and removing 
 entries in the server.xml and/or context.xml:
e.g. 

I’ve tried renaming the war file as ‘sru.war’ and placing it in webapps, 
removing other references to ‘sru’ in the configuration.

I think I’ve exhausted all possibilities of there being a duplicate ‘/sru’ 
context somehow, as many discussions indicate could be the cause. I haven’t 
explored the application itself to see if that is causing this problem – as the 
application works in one place with as close a configuration as I can get.

Annoyingly, I only need Linux for development and QA testing. It will be only 
deployed on Windows 2016 in phase 1 (and may never reach phase 2).

Any ideas where I should tweak next?

Thank you,
Tim

In case it helps, my immediate dependencies are summarised below. They mostly 
result from IntelliJ’s “create a new REST project”.

   *   javax.servlet:javax.servlet-api:4.0.1
   *   org.glassfish.jersey.containers:jersey-container-servlet:2.34
   *   org.glassfish.jersey.media:jersey-media-json-jackson:2.34
   *   org.glassfish.jersey.inject:jersey-cdi2-se:2.34
   *   org.glassfish.jersey.bundles:jaxrs-ri:2.13
   *   org.jboss.weld.se:weld-se-core:4.0.3.Final
   *   org.junit.jupiter:junit-jupiter-api:5.8.1
   *   org.junit.jupiter:junit-jupiter-engine:5.8.1
   *   javax.enterprise:cdi-api:2.0.SP1
   *   ch.qos.logback:logback-classic:1.2.10
   *   com.oracle.ojdbc:ojdbc8:19.3.0.0
   *   uk.org.lidalia:jul-to-slf4j-config:1.0.0
   *   org.slf4j:jul-to-slf4j:1.7.36
   *   org.eclipse.persistence:jakarta.persistence:2.2.3

--
Tim Scott
OCLC · Senior Software Engineer / Technical Product Manager

cc: IT file



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

NullPointerException in Tomcat startup while parsing XML configuration file

[Harri Pesonen]

Hello, I don't know if this is interesting, but while I started Tomcat in IDEA 
debugger, when I had breakpoint set to NullPointerException (so that it breaks 
on all of them),
then it break here:

org\apache\tomcat\tomcat-util\8.5.75\tomcat-util-8.5.75.jar!\org\apache\tomcat\util\IntrospectionUtils.class

public static String replaceProperties(String value, Hashtable 
staticProp, IntrospectionUtils.PropertySource[] dynamicProp, ClassLoader 
classLoader) {
if (value.indexOf(36) < 0) {

"value" is null.

A bit more up in stack trace, it is here:

org\apache\tomcat\tomcat-util-scan\8.5.75\tomcat-util-scan-8.5.75.jar!\org\apache\tomcat\util\digester\Digester.class

public InputSource resolveEntity(String name, String publicId, String baseURI, 
String systemId) throws SAXException, IOException {
name = this.replace(name);

"name" is null.

One more up:

java.xml\com\sun\org\apache\xerces\internal\util\EntityResolver2Wrapper.java

String name = null;
if (resourceIdentifier instanceof XMLDTDDescription) {
name = "[dtd]";
}
else if (resourceIdentifier instanceof XMLEntityDescription) {
name = ((XMLEntityDescription) resourceIdentifier).getEntityName();
}

// When both pubId and sysId are null, the user's entity resolver
// can do nothing about it. We'd better not bother calling it.
// This happens when the resourceIdentifier is a GrammarDescription,
// which describes a schema grammar of some namespace, but without
// any schema location hint. -Sg
if (pubId == null && sysId == null) {
return null;
}

// Resolve using EntityResolver2
try {
InputSource inputSource =
fEntityResolver.resolveEntity(name, pubId, baseURI, sysId);

"name" is null.

It was parsing this:

jar:file:/C:/Tomcat/tomcat_home/lib/catalina.jar!/org/apache/catalina/mbeans/mbeans-descriptors.xml

So the problem seems to happen in org.apache.xerces XML parser, or in Tomcat.

-Harri

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

Re: NullPointerException in Tomcat startup while parsing XML configuration file

[Christopher Schultz]

Harri,

On 3/14/22 10:23, Harri Pesonen wrote:

Hello, I don't know if this is interesting, but while I started Tomcat in IDEA 
debugger, when I had breakpoint set to NullPointerException (so that it breaks 
on all of them),
then it break here:

org\apache\tomcat\tomcat-util\8.5.75\tomcat-util-8.5.75.jar!\org\apache\tomcat\util\IntrospectionUtils.class

public static String replaceProperties(String value, Hashtable 
staticProp, IntrospectionUtils.PropertySource[] dynamicProp, ClassLoader classLoader) 
{
 if (value.indexOf(36) < 0) {

"value" is null.

A bit more up in stack trace, it is here:

org\apache\tomcat\tomcat-util-scan\8.5.75\tomcat-util-scan-8.5.75.jar!\org\apache\tomcat\util\digester\Digester.class

public InputSource resolveEntity(String name, String publicId, String baseURI, 
String systemId) throws SAXException, IOException {
 name = this.replace(name);

"name" is null.

One more up:

java.xml\com\sun\org\apache\xerces\internal\util\EntityResolver2Wrapper.java

String name = null;
if (resourceIdentifier instanceof XMLDTDDescription) {
 name = "[dtd]";
}
else if (resourceIdentifier instanceof XMLEntityDescription) {
 name = ((XMLEntityDescription) resourceIdentifier).getEntityName();
}

// When both pubId and sysId are null, the user's entity resolver
// can do nothing about it. We'd better not bother calling it.
// This happens when the resourceIdentifier is a GrammarDescription,
// which describes a schema grammar of some namespace, but without
// any schema location hint. -Sg
if (pubId == null && sysId == null) {
 return null;
}

// Resolve using EntityResolver2
try {
 InputSource inputSource =
 fEntityResolver.resolveEntity(name, pubId, baseURI, sysId);

"name" is null.

It was parsing this:

jar:file:/C:/Tomcat/tomcat_home/lib/catalina.jar!/org/apache/catalina/mbeans/mbeans-descriptors.xml

So the problem seems to happen in org.apache.xerces XML parser, or in Tomcat.


Have you modified the stock mbeans-descriptors.xml file? Does this 
prevent startup in your environment? If so, please post the full stack 
trace. If this error is caught and ignored, than there is nothing to do.


-chris

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

RE: [External] Re: Problems deploying new .war application on Linux

[Scott,Tim]

> From: Greg Huber 
> Sent: Monday, March 14, 2022 2:23 PM
> To: Tomcat Users List users@tomcat.apache.org
> Subject: [External] Re: Problems deploying new .war application on Linux

> On the sever where did tomcat come from? a rpm?
> Maybe as a test, download tomcat from tomcat.apache.org and see if it
makes a difference.

I always get my tomcats from tomcat.apache.org

😉.

Re: Rename version 10.1 to 11

[Jose Illescas]

Thank You for your response and link...

But I disagree with their opinion, because the "jakartization" of packages
it is a very rupturist change:

All libraries, frameworks and applications that run over a j2ee container
(tomcat, jetty, jboss...) must be changed or adapted. For me, this is
enough reason to force a mayor version change)

If you see from a developer point of view:

   - Versión 10.0 (supports Jakarta EE 9) disappeared when Jakarta EE 10
   released (as proposed in your link)
  - I prefer ignore the 10.0.X version (currently is latest and stable
  release of Tomcat) and wait until Tomcat 10.1.X released (support Jakarta
  EE 10).
 - Why I change all my applications to run over 10.0.X (Jakarta EE
 10)? when this versión 10.0.X will die in a "very" near future?
 - forced to me a double change, now, to run over Tomcat-10.0.X
 (Jakarta EE 10) and another change to run over Tomcat- 10.1.X version
 (Jakarta EE 11)

I see an forced version alignment between Tomcat and Jakarta EE

 Historically:

   - Tomcat 7.0.x : support Java EE 6
   - Tomcat 8.5.x : support Java EE 7
   - Tomcat 9.0.x : support Java EE 8
   - Tomcat 10.0.x : support Jakarta EE 9 (with my proposal)
   - Tomcat 11.0.x : support Jakarta EE 10 (with my proposal)
   - Tomcat 12.0.x : support Jakarta EE 11 (with my proposal)

New policy:

   - Tomcat 8.5.x : support Java EE 7
   - Tomcat 9.0.x : support Java EE 8
   - Tomcat 10.0.x : support Jakarta EE 9 (disappears when Jakarta EE 10
   released, developers must be readapt their apps to Jakarta EE 10)
   - Tomcat 10.1.x : support Jakarta EE 10 (confused with 10.0.x version,
   is not the same)
   - Tomcat 11.0.x : support Jakarta EE 11



On Sun, Mar 13, 2022 at 5:42 PM Mark Thomas  wrote:

> On 13/03/2022 13:29, Jose Illescas wrote:
> > I think that Tomcat mayor version must be change when updateing some of
> > their specs (servlet/jsp7/websockets/...)
> >
> > This strategy allow us to refer to tomcat with: Tomcat-9 or Tomcat-10
> > avoiding annoying names as tomcat-10.0.X or tomcat-10.1.X
> >
> >  IMHO I think that Tomcat 10.1.X version must be renamed to 11.X
>
> The community disagrees with your humble opinion.
>
>
> https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+Release+Numbering
>
> The plans for 9.10.x have evolved. Largely because the Tomcat API hasn't
> changed much between 9.0.x and 10.0.x/10.1.x.
>
> There is a commitment that there will be a Tomcat version that supports
> the Java EE 8 API (part from the minimum Java version requirement) for
> as long as there is a demand for it. Exactly what that ends up looking
> like is TBD. My current best guess is around the time 9.0.x reaches EOL
> we'll introduce 9.10.x that backports of lot of the changes in the
> 10.1.x branch. When 10.1.x reaches EOL we'll introduce 9.11.x etc.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: [External] Re: Problems deploying new .war application on Linux

[Greg Huber]

I’ve tried renaming the war file as ‘sru.war’ and placing it in webapps,
removing other references to ‘sru’ in the configuration.


I use ROOT.war and have no  stuff, just copy it into the 
webapps folder and use http://127.0.0.1:8080/ ie the default root app.


Does it explode the war file?

On 14/03/2022 14:44, Scott,Tim wrote:

From: Greg Huber 
Sent: Monday, March 14, 2022 2:23 PM
To: Tomcat Users List users@tomcat.apache.org
Subject: [External] Re: Problems deploying new .war application on Linux
On the sever where did tomcat come from? a rpm?
Maybe as a test, download tomcat from tomcat.apache.org and see if it

makes a difference.

I always get my tomcats from tomcat.apache.org

😉.



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

RE: [External] Re: Problems deploying new .war application on Linux

[Scott,Tim]

> From: Greg Huber gregh3...@gmail.com
> Sent: Monday, March 14, 2022 3:01 PM

> >I’ve tried renaming the war file as ‘sru.war’ and placing it in webapps,
> >removing other references to ‘sru’ in the configuration.

> I use ROOT.war and have no  stuff, just copy it into the
> webapps folder and use http://127.0.0.1:8080/ ie the 
> default root app.

The  experiments were an effort to try to get it to work in any form, 
rather than something I thought I needed.

> Does it explode the war file?
Yes – whether I used  or just plonked the .war file in 
webapps.

(Tempted to post on a Linux forum to play to the “Linux is better than Windows” 
brigade 😉 ).

Re: Rename version 10.1 to 11

[Christopher Schultz]

Jose,

On 3/14/22 10:55, Jose Illescas wrote:

Thank You for your response and link...

But I disagree with their opinion, because the "jakartization" of packages
it is a very rupturist change:

All libraries, frameworks and applications that run over a j2ee container
(tomcat, jetty, jboss...) must be changed or adapted. For me, this is
enough reason to force a mayor version change)

If you see from a developer point of view:

- Versión 10.0 (supports Jakarta EE 9) disappeared when Jakarta EE 10
released (as proposed in your link)
   - I prefer ignore the 10.0.X version (currently is latest and stable
   release of Tomcat) and wait until Tomcat 10.1.X released (support Jakarta
   EE 10).
  - Why I change all my applications to run over 10.0.X (Jakarta EE
  10)? when this versión 10.0.X will die in a "very" near future?
  - forced to me a double change, now, to run over Tomcat-10.0.X
  (Jakarta EE 10) and another change to run over Tomcat- 10.1.X version
  (Jakarta EE 11)


Note that Java 10 will auto-migrate older applications for you without 
modification. It's kind of a friendly bootstrapping feature to help 
developers make the transition to pre-Jakarta-EE to port-Jakarta-EE. 
You're welcome.



I see an forced version alignment between Tomcat and Jakarta EE

  Historically:

- Tomcat 7.0.x : support Java EE 6
- Tomcat 8.5.x : support Java EE 7
- Tomcat 9.0.x : support Java EE 8
- Tomcat 10.0.x : support Jakarta EE 9 (with my proposal)
- Tomcat 11.0.x : support Jakarta EE 10 (with my proposal)
- Tomcat 12.0.x : support Jakarta EE 11 (with my proposal)

 New policy:

- Tomcat 8.5.x : support Java EE 7
- Tomcat 9.0.x : support Java EE 8
- Tomcat 10.0.x : support Jakarta EE 9 (disappears when Jakarta EE 10
released, developers must be readapt their apps to Jakarta EE 10)
- Tomcat 10.1.x : support Jakarta EE 10 (confused with 10.0.x version,
is not the same)
- Tomcat 11.0.x : support Jakarta EE 11


This is entirely intentional: the version of Tomcat being aligned with 
the version of Jakarta EE was a somewhat happy accident. Back when 
servlet versions were the most important, there were 2.1, 2.2, 2.3, 2.4, 
2.5, then 3.0 and some of those resulted in different major versions of 
Apache Tomcat.


As Jakarta EE 9, 10, and 11 are announced, we saw were just one version 
off and that the transition from Java EE 8 to Jakarta EE was going to be 
a disaster for everyone.


What better way to help clarify things by adjusting our release 
numbering slightly so that the numbers match each other? It will be much 
better down the line.


I think a part of the problem is that you read too much into the actual 
numbering scheme. When you see 10.0 versus 10.1 you see a minor-feature 
release while we see a major release. This has happened at least twice 
before in recent Apache Tomcat memory: Tomcat 5.0 existed and then 
Tomcat 5.5 was released with major changes. The same is true for Tomcat 
8.0 and Tomcat 8.5. In both cases, we didn't go from N -> N+1 but 
instead N.0 -> N.0+∂. The changes were important enough to make it clear 
the versions weren't compatible with each other, but it didn't make 
sense to use a new whole version number. (In both cases, I believe 
Tomcat N+1 had either already been defined, or in fact already been 
/released/.)


So we're sorry if our decisions about the version numbering scheme are 
disturbing you. But the transition from Java EE to Jakarta EE is going 
to be a big mess and the version-numbering for Tomcat is the last of 
anyone's problems. Aligning to the Jakarta EE version will help 
everybody moving forward, so that's what we've chosen to do.


-chris


On Sun, Mar 13, 2022 at 5:42 PM Mark Thomas  wrote:


On 13/03/2022 13:29, Jose Illescas wrote:

I think that Tomcat mayor version must be change when updateing some of
their specs (servlet/jsp7/websockets/...)

This strategy allow us to refer to tomcat with: Tomcat-9 or Tomcat-10
avoiding annoying names as tomcat-10.0.X or tomcat-10.1.X

  IMHO I think that Tomcat 10.1.X version must be renamed to 11.X


The community disagrees with your humble opinion.


https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+Release+Numbering

The plans for 9.10.x have evolved. Largely because the Tomcat API hasn't
changed much between 9.0.x and 10.0.x/10.1.x.

There is a commitment that there will be a Tomcat version that supports
the Java EE 8 API (part from the minimum Java version requirement) for
as long as there is a demand for it. Exactly what that ends up looking
like is TBD. My current best guess is around the time 9.0.x reaches EOL
we'll introduce 9.10.x that backports of lot of the changes in the
10.1.x branch. When 10.1.x reaches EOL we'll introduce 9.11.x etc.

Mark

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

RE: Rename version 10.1 to 11

[Neil Aggarwal]

> Christopher Schultz wrote:
> So we're sorry if our decisions about the version numbering scheme are
> disturbing you.

Just to add another data point:
I don’t care about the numbering scheme as long as the code does what
I need it to do.  Tomcat works for me and does it very well.

I have to believe there are many other users that feel the same way.

Tomcat is a great product with amazing support from *volunteers*
who choose to spend them time helping others.  Thank you to all for that.

Thank you,
  Neil

--
Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com
We offer 30 year loans on single family houses!

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

Re: Rename version 10.1 to 11

[Jose Illescas]

Thank you very much, for your response and time...

   With time, I will see as normal the new versions

-jose

On Mon, Mar 14, 2022 at 5:36 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Jose,
>
> On 3/14/22 10:55, Jose Illescas wrote:
> > Thank You for your response and link...
> >
> > But I disagree with their opinion, because the "jakartization" of
> packages
> > it is a very rupturist change:
> >
> > All libraries, frameworks and applications that run over a j2ee container
> > (tomcat, jetty, jboss...) must be changed or adapted. For me, this is
> > enough reason to force a mayor version change)
> >
> > If you see from a developer point of view:
> >
> > - Versión 10.0 (supports Jakarta EE 9) disappeared when Jakarta EE 10
> > released (as proposed in your link)
> >- I prefer ignore the 10.0.X version (currently is latest and
> stable
> >release of Tomcat) and wait until Tomcat 10.1.X released (support
> Jakarta
> >EE 10).
> >   - Why I change all my applications to run over 10.0.X (Jakarta
> EE
> >   10)? when this versión 10.0.X will die in a "very" near future?
> >   - forced to me a double change, now, to run over Tomcat-10.0.X
> >   (Jakarta EE 10) and another change to run over Tomcat- 10.1.X
> version
> >   (Jakarta EE 11)
>
> Note that Java 10 will auto-migrate older applications for you without
> modification. It's kind of a friendly bootstrapping feature to help
> developers make the transition to pre-Jakarta-EE to port-Jakarta-EE.
> You're welcome.
>
> > I see an forced version alignment between Tomcat and Jakarta EE
> >
> >   Historically:
> >
> > - Tomcat 7.0.x : support Java EE 6
> > - Tomcat 8.5.x : support Java EE 7
> > - Tomcat 9.0.x : support Java EE 8
> > - Tomcat 10.0.x : support Jakarta EE 9 (with my proposal)
> > - Tomcat 11.0.x : support Jakarta EE 10 (with my proposal)
> > - Tomcat 12.0.x : support Jakarta EE 11 (with my proposal)
> >
> >  New policy:
> >
> > - Tomcat 8.5.x : support Java EE 7
> > - Tomcat 9.0.x : support Java EE 8
> > - Tomcat 10.0.x : support Jakarta EE 9 (disappears when Jakarta EE 10
> > released, developers must be readapt their apps to Jakarta EE 10)
> > - Tomcat 10.1.x : support Jakarta EE 10 (confused with 10.0.x
> version,
> > is not the same)
> > - Tomcat 11.0.x : support Jakarta EE 11
>
> This is entirely intentional: the version of Tomcat being aligned with
> the version of Jakarta EE was a somewhat happy accident. Back when
> servlet versions were the most important, there were 2.1, 2.2, 2.3, 2.4,
> 2.5, then 3.0 and some of those resulted in different major versions of
> Apache Tomcat.
>
> As Jakarta EE 9, 10, and 11 are announced, we saw were just one version
> off and that the transition from Java EE 8 to Jakarta EE was going to be
> a disaster for everyone.
>
> What better way to help clarify things by adjusting our release
> numbering slightly so that the numbers match each other? It will be much
> better down the line.
>
> I think a part of the problem is that you read too much into the actual
> numbering scheme. When you see 10.0 versus 10.1 you see a minor-feature
> release while we see a major release. This has happened at least twice
> before in recent Apache Tomcat memory: Tomcat 5.0 existed and then
> Tomcat 5.5 was released with major changes. The same is true for Tomcat
> 8.0 and Tomcat 8.5. In both cases, we didn't go from N -> N+1 but
> instead N.0 -> N.0+∂. The changes were important enough to make it clear
> the versions weren't compatible with each other, but it didn't make
> sense to use a new whole version number. (In both cases, I believe
> Tomcat N+1 had either already been defined, or in fact already been
> /released/.)
>
> So we're sorry if our decisions about the version numbering scheme are
> disturbing you. But the transition from Java EE to Jakarta EE is going
> to be a big mess and the version-numbering for Tomcat is the last of
> anyone's problems. Aligning to the Jakarta EE version will help
> everybody moving forward, so that's what we've chosen to do.
>
> -chris
>
> > On Sun, Mar 13, 2022 at 5:42 PM Mark Thomas  wrote:
> >
> >> On 13/03/2022 13:29, Jose Illescas wrote:
> >>> I think that Tomcat mayor version must be change when updateing some of
> >>> their specs (servlet/jsp7/websockets/...)
> >>>
> >>> This strategy allow us to refer to tomcat with: Tomcat-9 or Tomcat-10
> >>> avoiding annoying names as tomcat-10.0.X or tomcat-10.1.X
> >>>
> >>>   IMHO I think that Tomcat 10.1.X version must be renamed to 11.X
> >>
> >> The community disagrees with your humble opinion.
> >>
> >>
> >>
> https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+Release+Numbering
> >>
> >> The plans for 9.10.x have evolved. Largely because the Tomcat API hasn't
> >> changed much between 9.0.x and 10.0.x/10.1.x.
> >>
> >> There is a commitment that there will be a Tomcat version 

[ANN] Apache Tomcat 10.1.0-M12 (alpha) available

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 10.1.0-M12 (alpha).

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

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


Apache Tomcat 10.1.0-M12 is a milestone release of the 10.1.x branch and 
has been made to provide users with early access to the new features in 
Apache Tomcat 10.1.x so that they may provide feedback. The notable 
changes compared to 10.1.0-M11 include:


- Fix a potential thread-safety issue that could cause HTTP/1.1 request
  processing to pause, and potentially timeout, waiting for additional
  data when the full request has been received.

- Fix a regression introduced with 65757 bugfix which better identified
  non request threads but which introduced a similar problem when user
  code was doing sequential operations in a single thread.

- When resolving methods in EL expressions that use beans and/or static
  fields, ensure that any custom type conversion is considered when
  identifying the method to call.

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

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

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

Enjoy!

- The Apache Tomcat team

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

[ANN] Apache Tomcat 10.0.18 available

[Mark Thomas]

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

This release is targeted at Jakarta EE 9.

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


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

The notable changes compared to 10.0.17 include:

- Fix a potential thread-safety issue that could cause HTTP/1.1 request
  processing to pause, and potentially timeout, waiting for additional
  data when the full request has been received.

- Fix a regression introduced with 65757 bugfix which better identified
  non request threads but which introduced a similar problem when user
  code was doing sequential operations in a single thread.

- When resolving methods in EL expressions that use beans and/or static
  fields, ensure that any custom type conversion is considered when
  identifying the method to call.

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

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

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

Enjoy!

- The Apache Tomcat team

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

[ANN] Apache Tomcat 9.0.60 available

[Rémy Maucherat]

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

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

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

- Fix a potential thread-safety issue that could cause HTTP/1.1 request
   processing to pause, and potentially timeout, waiting for additional
   data when the full request has been received.

- Fix a regression introduced with 65757 bugfix which better identified
   non request threads but which introduced a similar problem when user
   code was doing sequential operations in a single thread.

- When resolving methods in EL expressions that use beans and/or static
   fields, ensure that any custom type conversion is considered when
   identifying the method to call.

Along with lots of other bug fixes and improvements.

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


Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

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