Hi Thomas,

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

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.


Tim Scott
OCLC · Senior Software Engineer / Technical Product Manager

cc: IT file

OCLC COVID-19 resources: 

From: Thomas Hoffmann (Speed4Trade GmbH) 
Sent: Monday, March 14, 2022 12:12 PM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: [External] AW: Problems deploying new .war application on Linux

> -----Ursprüngliche Nachricht-----
> Von: Scott,Tim <tim.sc...@oclc.org<mailto:tim.sc...@oclc.org>>
> Gesendet: Montag, 14. März 2022 11:16
> An: Tomcat Users List 
> <users@tomcat.apache.org<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<> on my PC. My first Linux 
> (RHEL 7) machine
> was using Corretto<> and is now 
> I placed the .war file, named ‘sru.war’ into a webapps folders on a stopped
> Windows 2016 Tomcat 9.0.54 / Corretto<> 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<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<http://ceConfig.java:248>)
> org.glassfish.jersey.server.ResourceConfig$ImmutableState.register(Resour
> http://ceConfig.java:195<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<http://ContainerInitializer.java:106>)
> at
> javax.enterprise.inject.se.SeContainerInitializer.newInstance(SeContainerIni
> http://tializer.java:97<http://tializer.java:97>)
> at
> org.glassfish.jersey.inject.cdi.se.CdiSeInjectionManager.completeRegistratio
> n(http://CdiSeInjectionManager.java:239<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 <Context> entries in the server.xml and/or context.xml:
> e.g. <Context path="/sru" docBase="/app/dev/tomcat/sru-1.0-
> SNAPSHOT.war"/>
> 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:
> * 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 
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/services


To unsubscribe, e-mail: 
For additional commands, e-mail: 

Reply via email to