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