I migrated my spring boot app for spring-boot 2.5.6 to spring-boot 2.6.2, but since then the start up tells
java.lang.IllegalStateException: Could not initialize Logback logging from classpath:logback-spring.groovyCaused by: ch.qos.logback.core.LogbackException:
Caused by: ch.qos.logback.core.LogbackException:Unexpected filename extension of file [file:/xyz/out/production/resources/logback-spring.groovy]. Should be either .groovy or .xml
Can someone help if you have a solution?
Thanks
Logback 1.2.9 dropped the support for Groovy.
You can either migrate your logback.groovy to logback.xml or downgrade the logback version to 1.2.7 (logback.version=1.2.7) and see if they’ll come around and support Groovy again (which they might).
Related
I am using spring boot version 2.1.5.Release, am trying to remove log4j 1.2.17 jar tried exclusion logic.inside spring boot starter dependency it's not worked. Could you please help me to fix the log4j issue. I tried upgrade of Spring boot version still I see dependency in my eclipse under maven dependencies..thanks in advance.
Check that you do not have the logging starter for log4j. If not, then in the dependency hierarchy in eclipse, right-click on log4j and it will let you exclude it from whatever is pulling it in as a transitive dependency.
I'm having issues getting Jersey 1.19 to work with log4j2 on Tomcat7. My project's working assembly against log4j1 consists of the following:
slf4j-api: 1.5.6
slf4j-log4j12: 1.5.6
log4j: 1.2.14
I have a test project using log4j2 working successfully (logs are written to a file) with the following:
slf4j-api: 1.5.6
slf4j-log4j12: 1.5.6
log4j-1.2-api: 2.11.0
log4j-api: 2.11.0
log4j-core: 2.11.0
I am including log4j-1.2-api and the slf4j-log4j12 for the 'bridge' between log4j 1 and 2 per documentation, as there is legacy code I am unable to touch that uses log4j1.
As soon as I remove log4j 1.2.14 from my real project's assembly, and add in the bridge (log4j-1.2-api) and the api and core for log4j2, I run into the following exception when the the first HTTP request hits the server after startup. Reverting back to log4j1 resolves the issue.
My log4j2.xml file (which works on the test project) is located in the servlets /WEB-INF/classes folder. I've also tried it in the /WEB-INF folder.
asm.jar is 3.3.1 if that matters - I see it in the stacktrace.
Is there a compatibility issue I haven't read about getting these to play together?
java.lang.IllegalArgumentException
jersey.repackaged.org.objectweb.asm.ClassReader.<init>(ClassReader.java:170)
jersey.repackaged.org.objectweb.asm.ClassReader.<init>(ClassReader.java:153)
jersey.repackaged.org.objectweb.asm.ClassReader.<init>(ClassReader.java:424)
com.sun.jersey.spi.scanning.AnnotationScannerListener.onProcess(AnnotationScannerListener.java:138)
com.sun.jersey.core.spi.scanning.JarFileScanner.scan(JarFileScanner.java:97)
com.sun.jersey.spi.scanning.servlet.WebAppResourcesScanner$1.f(WebAppResourcesScanner.java:94)
com.sun.jersey.core.util.Closing.f(Closing.java:71)
com.sun.jersey.spi.scanning.servlet.WebAppResourcesScanner.scan(WebAppResourcesScanner.java:92)
com.sun.jersey.spi.scanning.servlet.WebAppResourcesScanner.scan(WebAppResourcesScanner.java:79)
com.sun.jersey.api.core.ScanningResourceConfig.init(ScanningResourceConfig.java:80)
com.sun.jersey.api.core.servlet.WebAppResourceConfig.init(WebAppResourceConfig.java:102)
com.sun.jersey.api.core.servlet.WebAppResourceConfig.<init>(WebAppResourceConfig.java:89)
com.sun.jersey.api.core.servlet.WebAppResourceConfig.<init>(WebAppResourceConfig.java:74)
com.sun.jersey.spi.container.servlet.WebComponent.getWebAppResourceConfig(WebComponent.java:668)
com.sun.jersey.spi.container.servlet.ServletContainer.getDefaultResourceConfig(ServletContainer.java:435)
com.sun.jersey.spi.container.servlet.ServletContainer.getDefaultResourceConfig(ServletContainer.java:602)
com.sun.jersey.spi.container.servlet.WebServletConfig.getDefaultResourceConfig(WebServletConfig.java:87)
com.sun.jersey.spi.container.servlet.WebComponent.createResourceConfig(WebComponent.java:699)
com.sun.jersey.spi.container.servlet.WebComponent.createResourceConfig(WebComponent.java:674)
com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:205)
com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:394)
com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:577)
javax.servlet.GenericServlet.init(GenericServlet.java:158)
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:506)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:962)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:445)
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1115)
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:637)
org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpoint.java:2549)
org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:2538)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
java.lang.Thread.run(Thread.java:748)
TL;DR: Although Jersey 1.19.x can scan classes compiled with JDK 1.8, it fails on multi-release classes in META-INF/versions/9 compiled with JDK 9.
Remark: although this is an old question, even today there are some application using Jersey 1.19.x. Due to security problems they should upgrade to Log4j2 version 2.12.4 immediately if the run on Java 7 (which is itself a security risk) or the latest version if they run on Java 8+ (2.17.2 at the moment of writing). Since Jersey 1.19.x has no known security problems, its upgrade can be performed at a later time.
You have the same problem as in LOG4J2-3445: Log4j2 artifacts are multi-release, which means that most of the classes are compiled with Java 8 (supported by your old Jersey release), but some (in /META-INF/versions/9) are compiled with Java 9. The class scanner included in your Jersey version can not parse them.
You can try multiple workarounds:
Let Tomcat scan the classes instead of Jersey. This is available since Servlet 3.0 (Tomcat 7). To enable container annotation scanning in Jersey declare your servlet without a <servlet-class> parameter and a <servlet-name> equal to javax.ws.rs.core.Application:
<servlet>
<servlet-name>javax.ws.rs.core.Application</servlet-name>
</servlet>
This should also save up some startup time, since multiple Java EE technologies can profit of a single class scan.
If the workaround above does not solve your problem, you can restrict the paths scanned by Jersey using the com.sun.jersey.config.property.classpath servlet parameter (cf. javadoc). A setting of "/WEB-INF/classes" should be enough for most purposes.
Hy,
I'm using Spring Boot 1.5.7RELEASE with Flyway 4.2.0.
I have a problem with the configuration of the flyway.locations property for file system locations.
If I use file: prefix, I have Flyway error:
Caused by: org.flywaydb.core.api.FlywayException: Unknown prefix for location (should be either filesystem: or classpath:):
If I use filesystem: prefix, I have
Caused by: java.lang.IllegalStateException: Cannot find migrations location in:
What am I doing wrong ? (If I use classpath: everything is ok)
This appears to be a bug with FlywayAutoConfiguration in Spring Boot.
A workaround is to use the filesystem: prefix but disable location checking:
spring.flyway.check-location=false # spring boot 2.0.x
flyway.check-location=false # spring boot 1.5.x
I have raised an issue and submitted a PR.
Update
The fix was merged into Spring Boot 1.5.15 and 2.0.4.
I have a spring boot/liquibase app and after upgrading liquibase to 3.2.2 unit tests starts to print this exception, but tests still pass:
[WARN] liquibase - Error initializing SpringLiquibase
java.io.FileNotFoundException: ServletContext resource [/] cannot be resolved to URL because it does not exist
at org.springframework.web.context.support.ServletContextResource.getURL(ServletContextResource.java:156) ~[spring-web-4.0.7.RELEASE.jar:4.0.7.RELEASE]
at liquibase.integration.spring.SpringLiquibase$SpringResourceOpener.init(SpringLiquibase.java:74) [liquibase-core-3.2.2.jar:na]
at liquibase.resource.AbstractResourceAccessor.(AbstractResourceAccessor.java:19) [liquibase-core-3.2.2.jar:na]
at liquibase.integration.spring.SpringLiquibase$SpringResourceOpener.(SpringLiquibase.java:64) [liquibase-core-3.2.2.jar:na]
at liquibase.integration.spring.SpringLiquibase.createResourceOpener(SpringLiquibase.java:388) [liquibase-core-3.2.2.jar:na]
at liquibase.integration.spring.SpringLiquibase.createLiquibase(SpringLiquibase.java:349) [liquibase-core-3.2.2.jar:na]
at liquibase.integration.spring.SpringLiquibase.afterPropertiesSet(SpringLiquibase.java:300) [liquibase-core-3.2.2.jar:na]
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1613) [spring-beans-4.0.7.RELEASE.jar:4.0.7.RELEASE]
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1550) [spring-beans-4.0.7.RELEASE.jar:4.0.7.RELEASE]
at ...
Spring Boot doesn't support Liquibase 3.2.2 at the moment. I haven't seen the exact error that you've posted in the question, but I suspect it's another symptom of the incompatibilities between Liquibase 3.0.x and 3.2.x.
To be safe, you should stick with Liquibase 3.0.x for now, although I believe that 3.1.x may work as well.
There's an open Spring Boot issue describing some of the problems with 3.2.x. There's also an open Spring Boot pull request that provides compatibility with Liquibase 3.2.x. It's scheduled for inclusion in Spring Boot 1.2 which is due for release in Novemeber.
Just moved to Grails 1.2.1 (used 1.1.1 before). Changed application.properties, ran grails upgrade, fixed BuildConfig and Bootstrap - everything works just fine from grails console.
However, getting a problem when deploy packaged war under jetty 6.1.22:
1581 [main] ERROR org.springframework.web.context.ContextLoader - Context initialization failed org.springframework.beans.factory.access.BootstrapException: Error executing bootstraps; nested exception is java.lang.NoSuchMethodError: org.codehaus.groovy.grails.commons.spring.ReloadAwareAutowireCapableBeanFactory.setParameterNameDiscoverer(Lorg/springframework/core/ParameterNameDiscoverer;)V
My project is built with maven2. I researched the war dependencies and see that both spring 2.5.6 and 3.0.0.RELEASE are used there.
I then tried to suppress use of spring 2.5.6 and got a problem with Acegi plugin (using version 0.5.1):
2010-03-10 21:06:56.440:WARN::Nested in org.springframework.beans.factory.access.BootstrapException: Error executing bootstraps; nested exception is java.lang.NoSuchMethodError: org.springframework.web.context.ConfigurableWebApplicationContext.setId(Ljava/lang/String;)V
Any help would be greatly appreciated.
The problem is caused by the fact that in new version of Spring
ConfigurableWebApplicationContext is located in spring-web.jar, but the interface it inherits ConfigurableApplicationContext, which contains setId(String) method is in located in spring-context.jar.
If you have a library which has been compiled against older version of spring-context it will fail with NoMethodFound exception.
The solution is to locate and recompile that library against latest Spring version.
If you are using Spring version below 3.0 you could try to put full Spring bundle Jar instead of separate packages.