You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Scott,Tim" <Ti...@oclc.org> on 2022/03/14 10:16:06 UTC
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(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
RE: [External] Re: Problems deploying new .war application on Linux
Posted by "Scott,Tim" <Ti...@oclc.org>.
> From: Greg Huber gregh3269@gmail.com<ma...@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 <context/> stuff, just copy it into the
> webapps folder and use http://127.0.0.1:8080/<http://127.0.0.1:8080> ie the default root app.
The <context> 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 <context / docBase> 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
Posted by Greg Huber <gr...@gmail.com>.
>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 <context/> 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 <gr...@gmail.com>
>> Sent: Monday, March 14, 2022 2:23 PM
>> To: Tomcat Users List users@tomcat.apache.org<ma...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [External] Re: Problems deploying new .war application on Linux
Posted by "Scott,Tim" <Ti...@oclc.org>.
> From: Greg Huber <gr...@gmail.com>
> Sent: Monday, March 14, 2022 2:23 PM
> To: Tomcat Users List users@tomcat.apache.org<ma...@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
Posted by Greg Huber <gr...@gmail.com>.
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 <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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Problems deploying new .war application on Linux
Posted by "Scott,Tim" <Ti...@oclc.org>.
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<https://oc.lc/covid19-service-info>
From: Thomas Hoffmann (Speed4Trade GmbH) <Th...@speed4trade.com.INVALID>
Sent: Monday, March 14, 2022 12:12 PM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: [External] AW: Problems deploying new .war application on Linux
> -----Ursprüngliche Nachricht-----
> Von: Scott,Tim <Ti...@oclc.org>>
> Gesendet: Montag, 14. März 2022 11:16
> An: Tomcat Users List <us...@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<http://11.0.14.1> on my PC. My first Linux (RHEL 7) machine
> was using Corretto 11.0.11.9<http://11.0.11.9> and is now 11.0.14.10<http://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<http://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<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: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-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
RE: Problems deploying new .war application on Linux
Posted by "Scott,Tim" <Ti...@oclc.org>.
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' <us...@tomcat.apache.org>
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<ma...@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
Posted by "Scott,Tim" <Ti...@oclc.org>.
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<https://oc.lc/covid19-service-info>
AW: Problems deploying new .war application on Linux
Posted by "Thomas Hoffmann (Speed4Trade GmbH)" <Th...@speed4trade.com.INVALID>.
> -----Ursprüngliche Nachricht-----
> Von: Scott,Tim <Ti...@oclc.org>
> Gesendet: Montag, 14. März 2022 11:16
> An: Tomcat Users List <us...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org