I'm fairly new to spring and spring boot so am not 100 percent sure what i'm doing... Up until a few days ago everything was working fine with my springboot application, but now it throws this error upon starting:
Exception encountered during context initialization - cancelling refresh attempt: org.springframework.context.ApplicationContextException: Unable to start embedded container; nested exception is java.lang.NoSuchMethodError: org.apache.catalina.Server.setCatalinaBase(Ljava/io/File;)V
After some reading around people are saying that the version of tomcat might be outdated, but I'm not really sure where to start
You need to provide us information which version of tomcat and spring boot you are using. I guess you are having problem that your spring boot version is in collision with tomcat version.(One version of spring boot cannot work with all versions of tomcat, I guess that if your application worked before then it must be that you changed, added or deleted some dependency and that is the reason why you app don't work now)
Related
We've been getting errors occasionally from our test and production environments where ServiceLocatorImpl has shut down which causes it to fail to create stateless EJBs from any #Schedule methods.
javax.ejb.EJBException: javax.ejb.EJBException: javax.ejb.CreateException: Could not create stateless EJB
at com.sun.ejb.containers.StatelessSessionContainer._getContext(StatelessSessionContainer.java:399)
at com.sun.ejb.containers.BaseContainer.getContext(BaseContainer.java:2607)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:2024)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:210)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:90)
...
Caused by: java.lang.IllegalStateException: ServiceLocatorImpl(__HK2_Generated_9,12,566324949) has been shut down
at org.jvnet.hk2.internal.ServiceLocatorImpl.checkState(ServiceLocatorImpl.java:2384)
at org.jvnet.hk2.internal.ServiceLocatorImpl.inject(ServiceLocatorImpl.java:997)
at org.glassfish.jersey.inject.hk2.AbstractHk2InjectionManager.inject(AbstractHk2InjectionManager.java:207)
at org.glassfish.jersey.inject.hk2.ImmediateHk2InjectionManager.inject(ImmediateHk2InjectionManager.java:30)
at org.glassfish.jersey.ext.cdi1x.internal.CdiComponentProvider$InjectionManagerInjectedCdiTarget.inject(CdiComponentProvider.java:668)
at org.glassfish.weld.services.JCDIServiceImpl$JCDIInjectionContextImpl.inject(JCDIServiceImpl.java:581)
at org.glassfish.weld.services.JCDIServiceImpl.injectEJBInstance(JCDIServiceImpl.java:328)
at com.sun.ejb.containers.BaseContainer.injectEjbInstance(BaseContainer.java:1818)
at com.sun.ejb.containers.StatelessSessionContainer.createStatelessEJB(StatelessSessionContainer.java:437)
... 88 more
Most of the application continues to work fine and and users can continue using it but background processes that are run from #Schedule all fail until we restart Payara.
We originally ran into this in our test environment after it had been running for multiple days under a fairly high load while we were on Payara 5.2021.4 (uses Jersey 2.30). We found servicelocator impl shutdown issue in jersey 2.22 talking about this issue and it seemed to indicate that Jersey 2.26 fixed the issue.
Since we were already on a later version we dug into the release notes and found that in hk2 2.6.1 there was a fix "Fix for child service locator shutdown" (https://github.com/eclipse-ee4j/glassfish-hk2/blob/master/CHANGELOG) and that Jersey 2.29.1 had updated the hk2 version from 5.1.0 to 6.2.1 (https://github.com/eclipse-ee4j/jersey/pull/4234) and that we had been listing Jersey 2.29 as a dependency. So we updated our versions to Payara 5.2021.8, Jersey 2.34 (hk2 2.6.1) and made our environment restart payara every night. After that we didn't seen the error for a while but since then we've still gotten it a couple times in production.
We haven't been able to reproduce the issue on demand or pin down any other errors that could be causing it. Has anyone else run into this issue on the current Payara and come up with a way to fix it, work around it or mitigate it short of restarting payara whenever it happens?
I know that this is a very trivial question but please suggest me to find the way. Sometimes when I start Spring Boot server, it stops but it does not display the complete error/exception stack trace. Think of situation that spring boot server has been started in 8080 port and if somebody starts in 8080 port, it should clearly display that java.net.BindException. But in my case server simply aborts.
I normally find the issue from the IDE like eclipse/Idea when I start the server in debug mode. But how to find the error when somebody starts spring boot server using command prompt ? There may be many errors for which spring boot is unable to start. My question is what configurations should be added in application.properties to know more details about the error/s for which spring boot is not getting started. Currently I am using Spring Boot 2.1.1.RELEASE version. Please help me fix this.
To see more details of the actions being carried out for a spring boot application, change the log level to debug. You can do it just by simply adding below lines in application.property/yaml file.
logging.level.=DEBUG
Or for web applications you can try
logging.level.org.springframework.web: DEBUG
Add the below property in application.xml - worked in Spring boot 2.2.4
logging.level.root:ERROR
A couple of weeks ago, I upgraded the version of Spring from to 1.4.x.RELEASE to 1.5.1.RELEASE.
Suddenly it has become a fight to start my Spring Boot service due this error:
"The dependencies of some of the beans in the application context form a cycle"
Same code, different version
It's quite funny, since on my local env (OSX) the same code is usually starting fine, but on Heroku is failing randomly on different deploys (looks like a different order on classpath Class resolution, due OS or due different JDK implementations)
I have even refactored the code to use field injection instead of constructor one everywhere without success.
Any suggestion? why this Spring version has suddenly started to produce these errors?
Thanks!
Find out which bean(s) is the reason for cycle from logs and use #Lazy annotation with #Autowired for this bean(s) in your code. For most cases this should do the trick.
Im having some weird issues using spring security. When i try to start my tomcat server, the following exception is thrown:
Couldn't locate: org.springframework.ldap.core.support.BaseLdapPathContextSource. If you are using LDAP with Spring Security, please ensure that you include the spring-ldap jar file in your application;
I have almost every spring library included in my maven dependencies:
spring-security-web-3.1.4.RELEASE.jar
spring-security-core-3.1.4.RELEASE.jar
spring-security-config-3.1.4.RELEASE.jar
spring-security-ldap-3.1.4.RELEASE.jar
spring-security-acl-3.1.4.RELEASE.jar
spring-security-taglibs-3.1.4.RELEASE.jar
spring-ldap-core-1.3.2.RELEASE.jar
spring-core-3.1.4.RELEASE.jar
spring-beans-3.1.4.RELEASE.jar
spring-aop-3.1.4.RELEASE.jar
spring-web-3.1.4.RELEASE.jar
spring-context-3.1.4.RELEASE.jar
spring-jdbc-3.1.4.RELEASE.jar
spring-tx-3.1.4.RELEASE.jar
spring-asm-3.1.4.RELEASE.jar
spring-expression-3.0.7.RELEASE.jar
What could be possibly causing this problem? Thanks in advance.
Solved my problem by simply downgrading to a older version of spring security. No problems happened since then.
I have a strange behavior of Glassfish 3.1.2.2 (build 5) running on OpenIndiana 151.a3
Using oracle jdk 1.7.0_5.
When i deploy my web application which has a spring web dispatcher and stripes servlet
I get them initialized twice in a row e.g.
PWC1412: WebModule[null] ServletContext.log():Initializing Spring root WebApplicationContext|#]
INFO StripesFilter - Stripes Initialization Complete. Version: 1.5.6, Build: 1.5.6
PWC1412: WebModule[null] ServletContext.log():Initializing Spring root WebApplicationContext|#]
INFO StripesFilter - Stripes Initialization Complete. Version: 1.5.6,
Build: 1.5.6
WEB0671: Loading application [my-web] at [/my-web]|#]
That wouldn't be a much problem if not for an blazeds servlet that i initialize from spring which fails completely on second initialization. I tried disabling blazeds servlet but that doesn't solve double initialization problem because i still get messages of initialization twice in a log. And my application wouldn't work without blazeds so i'm in a pinch here.
UPDATE: I've confirmed it only happens on OpenIndiana host, same configuration on linux works without issues
We had a similar problem. We also tried to deploy to a particular virtual server, which did not work. To fix the issue I ended up having to manually delete the extra virtual-server from the domain.xml:
<virtual-server id="admin-server" network-listeners="http-listener-2"></virtual-server>
If you have more than one virtual server:
"If you deploy a web application and don't specify any assigned virtual servers, the web application is assigned to all currently defined virtual servers"
http://docs.oracle.com/cd/E18930_01/html/821-2416/ggncs.html
But this did not solve our problem.
We had to delete the extra virtual server for it to work. This also happens on 3.1.2 and it is not just a windows problem. We replicated the issue on Linux too.