> -----Ursprüngliche Nachricht----- > Von: Scott,Tim <tim.sc...@oclc.org> > Gesendet: Montag, 14. März 2022 11:16 > An: Tomcat Users List <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 > 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 <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
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/services Greetings, Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
