RE: Problems deploying new .war application on Linux

[Scott,Tim]

Hi all,

If only for the email archives – just a note to say that I have not yet found a 
solution.

Thanks,
Tim

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

cc: IT file

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

From: Scott,Tim
Sent: Tuesday, March 15, 2022 2:45 PM
To: 'Tomcat Users List' 
Subject: RE: Problems deploying new .war application on Linux

Hi Thomas,

> Another approach is to do remote debugging and step into the class with the 
> error 
> (javax.enterprise.inject.se.SeContainerInitializer.findSeContainerInitializer)
I set an Exception breakpoint on IllegalStateException and this opened the 
class for me to set a breakpoint prior to the exception.

When I retried that, I can see that the ServiceLoader is passed:
ParallelWebappClassLoader
  context: sru
  delegate: false
--> Parent Classloader:
java.net.URLClassLoader@1623b78d<mailto:java.net.URLClassLoader@1623b78d>

Under loader / resources / classResources, the list includes:
#37 = 
file:/app/dev/tomcat/webapps/sru/WEB-INF/lib/jakarta.enterprise.cdi-api-3.0.0.jar
#51 = file:/app/dev/tomcat/webapps/sru/WEB-INF/lib/cdi-api-2.0.SP1.jar
#52 = file:/app/dev/tomcat/webapps/sru/WEB-INF/lib/jersey-cdi2-se-2.34.jar

When I compare this with a breakpoint prior to that exception, deployed on my 
PC, the breakpoint is never reached.

When I set a breakpoint in the ServiceLoader class/load() method on my PC and 
skip through to each pause I can see that it does not get called to find 
SeContainerInitializer.

I had hoped to compare the ClassLoader passed in to ServiceLoader.load() to 
help pin down the problem. I had not expected an absence of a call to the 
method!

Any further ideas?

Thanks,
Tim

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

cc: IT file

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

RE: Problems deploying new .war application on Linux

[Scott,Tim]

Hi Thomas,

> Another approach is to do remote debugging and step into the class with the 
> error 
> (javax.enterprise.inject.se.SeContainerInitializer.findSeContainerInitializer)
I set an Exception breakpoint on IllegalStateException and this opened the 
class for me to set a breakpoint prior to the exception.

When I retried that, I can see that the ServiceLoader is passed:
ParallelWebappClassLoader
  context: sru
  delegate: false
--> Parent Classloader:
java.net.URLClassLoader@1623b78d

Under loader / resources / classResources, the list includes:
#37 = 
file:/app/dev/tomcat/webapps/sru/WEB-INF/lib/jakarta.enterprise.cdi-api-3.0.0.jar
#51 = file:/app/dev/tomcat/webapps/sru/WEB-INF/lib/cdi-api-2.0.SP1.jar
#52 = file:/app/dev/tomcat/webapps/sru/WEB-INF/lib/jersey-cdi2-se-2.34.jar

When I compare this with a breakpoint prior to that exception, deployed on my 
PC, the breakpoint is never reached.

When I set a breakpoint in the ServiceLoader class/load() method on my PC and 
skip through to each pause I can see that it does not get called to find 
SeContainerInitializer.

I had hoped to compare the ClassLoader passed in to ServiceLoader.load() to 
help pin down the problem. I had not expected an absence of a call to the 
method!

Any further ideas?

Thanks,
Tim

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

cc: IT file

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

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: [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<mailto: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 
> Sent: Monday, March 14, 2022 2:23 PM
> To: Tomcat Users List users@tomcat.apache.org<mailto: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: 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

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
> *