I'm looking to minimize the size of my software distribution, and groovy-all.jar is by far the biggest JAR. Groovy is used for logback configuration[1]. On the bottom of the Groovy download page there's a section on the split Groovy distribution.
Which modules / JAR files does logback need to function properly? Is just groovy.jar sufficient?
[1] Yes, I realize I could configure logback with XML, eliminating the need for Groovy support. That is not my question.
I haven't found a source, but as of logback version 1.0.13 my tests show that groovy-jsr223 is needed as well. If I import only groovy in my pom.xml, logback complains about missing classes. The error message is
ERROR in ch.qos.logback.classic.LoggerContext[default] - Groovy classes are not available on the class path. ABORTING INITIALIZATION.
My dependency configuration that works is:
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>1.0.13</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy</artifactId>
<version>2.5.8</version>
<type>pom</type>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-jsr223</artifactId>
<version>2.5.8</version>
<type>pom</type>
<scope>test</scope>
</dependency>
Related
In a simple Maven project, that I am editing with Eclipse 2022-12 and installing and testing with m2e, I am getting this warning in Eclipse Error Log window:
!ENTRY org.eclipse.m2e.logback.appender 2 0 2023-02-09 16:30:22.592
!MESSAGE sourceFile /home/rsc/share/eclipse-workspace/HelloClient/src/test/resources/logback-test.xml not found during incremental build
My pom.xml specifies to use slf4j with log4j2
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>2.0.6</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.19.0</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-slf4j2-impl</artifactId>
<version>2.19.0</version>
</dependency>
When I run mvn test from the command line, no such warning occurs. Hence, no need to use logback.
Why does m2e ask for logback and how can I avoid it?
I am new to spring boot and when I try to start my server , I get the following Exception. I understand that this has something to do with dependency conflict, but still unable to figure it out.I am using maven to manage my dependencies.Please help
Exception in thread "main" java.lang.IllegalArgumentException:
LoggerFactory is not a Logback LoggerContext but Logback is on the
classpath. Either remove Logback or the competing implementation
(class org.slf4j.impl.Log4jLoggerFactory) Object of class
[org.slf4j.impl.Log4jLoggerFactory] must be an instance of class
ch.qos.logback.classic.LoggerContext at
org.springframework.util.Assert.isInstanceOf(Assert.java:339) at
org.springframework.boot.logging.logback.LogbackLoggingSystem.initialize(LogbackLoggingSystem.java:93)
at
org.springframework.boot.logging.AbstractLoggingSystem.initializeWithSensibleDefaults(AbstractLoggingSystem.java:62)
at
org.springframework.boot.logging.AbstractLoggingSystem.beforeInitialize(AbstractLoggingSystem.java:45)
at
org.springframework.boot.logging.logback.LogbackLoggingSystem.beforeInitialize(LogbackLoggingSystem.java:69)
at
org.springframework.boot.logging.LoggingApplicationListener.onApplicationEvent(LoggingApplicationListener.java:135)
at
org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:98)
at
org.springframework.boot.context.event.EventPublishingRunListener.publishEvent(EventPublishingRunListener.java:100)
at
org.springframework.boot.context.event.EventPublishingRunListener.started(EventPublishingRunListener.java:54)
at
org.springframework.boot.SpringApplication.run(SpringApplication.java:276)
at
org.springframework.boot.SpringApplication.run(SpringApplication.java:952)
at
org.springframework.boot.SpringApplication.run(SpringApplication.java:941)
at org.magnum.mobilecloud.video.Application.main(Application.java:30)
Resolved:Add the following to the POM.xml
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
<exclusions>
<exclusion>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
</exclusion>
<exclusion>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-log4j</artifactId>
</dependency>
Excluding logback-classic from spring-boot-starter-web and spring-boot-starter-actuator worked for me
compile("org.springframework.boot:spring-boot-starter-web:1.1.10.RELEASE") {
exclude module: "spring-boot-starter-tomcat"
exclude module: "spring-boot-starter-logging"
exclude module: "logback-classic"
}
compile("org.springframework.boot:spring-boot-starter-actuator:1.1.10.RELEASE") {
exclude module: "logback-classic"
}
Add this to your build.gradle
configurations.all {
exclude group: 'org.springframework.boot', module: 'spring-boot-starter-tomcat'
exclude group: 'org.springframework.boot', module: 'spring-boot-starter-logging'
exclude group: 'org.springframework.boot', module: 'logback-classic'
}
In my project, it is using
spring boot 1.4.2.RELEASE
both slf4j 1.7.21 and logback 1.1.7. (some dependency , called module A, depend on logback 1.1.2, this is the issue)
First Introduction to the Dependency Mechanism
Dependency mediation - this determines what version of a dependency will be used when multiple versions of an artifact are encountered. Currently, Maven 2.0 only supports using the "nearest definition" which means that it will use the version of the closest dependency to your project in the tree of dependencies. You can always guarantee a version by declaring it explicitly in your project's POM. Note that if two dependency versions are at the same depth in the dependency tree, until Maven 2.0.8 it was not defined which one would win, but since Maven 2.0.9 it's the order in the declaration that counts: the first declaration wins.
"nearest definition" means that the version used will be the closest one to your project in the tree of dependencies, eg. if dependencies for A, B, and C are defined as A -> B -> C -> D 2.0 and A -> E -> D 1.0, then D 1.0 will be used when building A because the path from A to D through E is shorter. You could explicitly add a dependency to D 2.0 in A to force the use of D 2.0
So maven will use logback 1.1.7 in my project. I am not sure it is my module A not compatible with 1.1.7 or logback 1.1.7 not compatible with slf4j 1.7.21
Whatever, in my case. I add dependencyManagement in my pom. Tell maven use lockback 1.1.2 only. Problem solved.
<dependencyManagement>
<dependencies>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>1.1.2</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-core</artifactId>
<version>1.1.2</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-access</artifactId>
<version>1.1.2</version>
</dependency>
</dependencies>
</dependencyManagement>
the following configuration in my gradle.build file worked for me:
configurations {
all*.exclude group: "org.springframework.boot", module: "spring-boot-starter-logging"
all*.exclude group: "ch.qos.logback"
all*.exclude group: "org.slf4j", module: "log4j-over-slf4j" // allow using log4j 2.x
all*.exclude group: "org.slf4j", module: "slf4j-simple" // log4j is the configured backend
}
Repeat answer but you can use Eclipse to exclude the spring-boot-starter-logging dependency
Select dependency hierarchy
Search for logging top right
Select spring-boot-starter-logging
Right click exclude maven artifact
e.g
enter image description here
Gradle solution is adding below lines in build.gradle :
configurations {
all*.exclude module : 'spring-boot-starter-logging'
}
I would recommend you to try removing any dependency that contains the Logback, the most common one is:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-log4j2</artifactId>
</dependency>
It worked for me.
Spring Boot supports Log4j 2 for logging configuration if it is on the classpath. If you use the starters for assembling dependencies, you have to exclude Logback and then include log4j 2 instead.
Resolved the issue by adding the below dependencies in this order
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-log4j2</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
<exclusions>
<exclusion>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
</exclusion>
<exclusion>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
Finally resolved this issue by excluding the Logback dependency and explicitly adding the log4j dependency
I am currently unable to connect to my cassandra database using the datastax driver. I am getting the following error:
com.datastax.driver.core.TransportException: [/127.0.0.1] Unexpected exception triggered (java.lang.NoSuchMethodError: com.google.common.collect.ImmutableSet.copyOf(Ljava/util/Collection;)Lcom/google/common/collect/ImmutableSet;)
at com.datastax.driver.core.Connection$Dispatcher.exceptionCaught(Connection.java:556)
at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:122)
Caused by: java.lang.NoSuchMethodError: com.google.common.collect.ImmutableSet.copyOf(Ljava/util/Collection;)Lcom/google/common/collect/ImmutableSet;
at com.datastax.driver.core.DataType.<clinit>(DataType.java:144)
at com.datastax.driver.core.Codec.<clinit>(Codec.java:31)
However, I have included the guava artefact in my pom.xml as follows:
<!-- Datastax driver -->
<dependency>
<groupId>com.datastax.cassandra</groupId>
<artifactId>cassandra-driver-core</artifactId>
<version>1.0.4</version>
</dependency>
<!-- Cassandra -->
<dependency>
<groupId>org.apache.cassandra</groupId>
<artifactId>cassandra-all</artifactId>
<version>1.2.9</version>
</dependency>
<!-- guava --<
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>15.0</version>
</dependency>
Full pom.xml: http://pastebin.ubuntu.com/6358603/
Am I missing a dependency?
According to its POM, version 1.0.4 of cassandra-driver-core uses version 14.0.1 of Guava, not version 15.0. I'm guessing you are seeing a version clash. Even if that version difference is not the cause of this problem, it might cause other problems.
You do not usually need to include transitive dependencies in POMs, Maven takes care of them for you. Or does your own code use Guava itself?
Based on the advice of this question: no such method error: ImmutableList.copyOf()
I had to exclude the google collections jar:
<dependency>
<groupId>org.zkoss.zk</groupId>
<artifactId>zkspring-core</artifactId>
<version>3.1</version>
<exclusions>
<exclusion>
<groupId>com.google.collections</groupId>
<artifactId>google-collections</artifactId>
</exclusion>
</exclusions>
</dependency>
I have a war web application which is using Tapestry framework. It uses slf4j + log4j and works well.
I also have a simple server application with embedded jetty 8 which I am using to deploy the war.
I would like to use slf4j + log4j in the server as well.
Therefore I add the slf4j and log4j dependency to my server pom.xml:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.5</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.7.5</version>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.17</version>
</dependency>
I get:
SLF4J: Class path contains multiple SLF4J bindings.<br/>
SLF4J: Found binding in [jar:file:/tmp/jetty-0.0.0.0-8080-web-app-0.0.1.war-_-any-/webapp WEB-INF/lib/slf4j-log4j12-1.6.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/home/martin/monitoring-gui/trunk/release/target/release-0.0.1-webgui-distribution/release-0.0.1/lib/slf4j-log4j12-1.7.5.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]
Fair enough, Tapestry dependency automatically includes slf4j-log4j12 and log4j. So I add following to my webapp pom.xml tapestry-core section:
<exclusions>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
</exclusion>
<exclusion>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
</exclusion>
</exclusions>
Now, the actual binding and logger should only be present in the server application.
However upon server start I get:
Exception in thread "main" java.lang.LinkageError: loader constraint violation: when resolving method "org.slf4j.impl.StaticLoggerBinder.getLoggerFactory()Lorg/slf4j/ILoggerFactory;" the class loader (instance of org/eclipse/jetty/webapp/WebAppClassLoader) of the current class, org/slf4j/LoggerFactory, and the class loader (instance of sun/misc/Launcher$AppClassLoader) for resolved class, org/slf4j/impl/StaticLoggerBinder, have different Class objects for the type taticLoggerBinder.getLoggerFactory()Lorg/slf4j/ILoggerFactory; used in the signature
at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:299)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:269)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:281)
at org.apache.tapestry5.TapestryFilter.<init>(TapestryFilter.java:56)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at java.lang.Class.newInstance(Class.java:374)
at org.eclipse.jetty.servlet.ServletContextHandler$Context.createFilter(ServletContextHandler.java:1051)
at org.eclipse.jetty.servlet.FilterHolder.doStart(FilterHolder.java:104)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:763)
at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:265)
at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1242)
at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:717)
at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:494)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:95)
at org.eclipse.jetty.server.Server.doStart(Server.java:282)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
...
going all the way to my jetty Server.start() call;
What am I missing?
You have a dependency problem. Instead of using exclusion all the time I see the dependency tree and reorder the tags inside pom.xml. The rule here seams that the first appearance of the dependency wins. So when you want that a inherited dependency is omitted by another one, just move the dependency tag before the one you want the inherited dependency omitted.
That makes the pom more readable and also controls which version of the dependencies in the trees are used. In only rare cases I have to use the tag.
The problem is that you have two versions of slf4j-log4j12 on your classpath. By the looks of it you are managing to exclude the later version in stead of the older one. Slf4j is complaining about the fact it is expecting a newer version than the one it is finding.
It seems to me that the 1.6.1 version makes it onto your classpath though your embedded jetty server. Have you setup your jetty dependency through maven as well? If so, add the exclude to your jetty dependency too. Either way, you need to inspect your classpath and resolve the conflicting versions one way or the other
Alright, thanks for help joostschouten and user2424794. I've got it working.
The mvn dependency:tree revealed, that other web app's dependency: qpid-client imported another slf4j-api to the war.
So another exclusion was necessary:
<dependency>
<groupId>org.apache.qpid</groupId>
<artifactId>qpid-client</artifactId>
<version>0.22</version>
<exclusions>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
</exclusion>
</exclusions>
</dependency>
For the record, the tapestry-core dependency:
<dependency>
<groupId>org.apache.tapestry</groupId>
<artifactId>tapestry-core</artifactId>
<version>${tapestry-release-version}</version>
<exclusions>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
</exclusion>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
</exclusion>
<exclusion>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
</exclusion>
</exclusions>
</dependency>
The only problem left is that the war wouldn't compile without the slf4j-api, therefore I add it as war dependency for the compilation, not for the linking - maven's provided scope:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.5</version>
<scope>provided</scope>
</dependency>
Of course, the slf4j-api , slf4j-log4j12 and log4j are added as dependencies for the server, which 'provides' it to the war application.
Now everything compiles, runs and logs just fine.
I want to build a JSF project with MAVEN. I tried to add the all dependencies i needed. Each time I get the errors.
<dependencies>
<dependency>
<groupId>org.richfaces</groupId>
<artifactId>richfaces-bom</artifactId>
<type>pom</type>
<version>4.2.2.Final</version>
</dependency>
<dependency>
<groupId>org.apache.myfaces.core</groupId>
<artifactId>myfaces-impl</artifactId>
<version>2.0.2</version>
</dependency>
<dependency>
<groupId>org.apache.myfaces.core</groupId>
<artifactId>myfaces-api</artifactId>
<version>2.0.2</version>
<scope>compile</scope>
</dependency>
</dependencies>
What should I add to this POM so that my project works as a real JSF project?
P.S I added the right richfaces dependencies. I got deploy problems on websphere like.
Caused by: javax.faces.FacesException: java.lang.UnsupportedOperationException
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:387)
at com.ibm.ws.webcontainer.webapp.WebApp.notifyServletContextCreated(WebApp.java:1651)
at com.ibm.ws.webcontainer.webapp.WebAppImpl.initialize(WebAppImpl.java:410)
at com.ibm.ws.webcontainer.webapp.WebGroupImpl.addWebApplication(WebGroupImpl.java:88)
at com.ibm.ws.webcontainer.VirtualHostImpl.addWebApplication(VirtualHostImpl.java:169)
... 17 more
Caused by: java.lang.UnsupportedOperationException
at com.sun.faces.config.ConfigureListener$ApplicationMap.entrySet(ConfigureListener.java:1948)
The Richfaces dependency you are using is just a bom - it lists a set of compatible "real" dependencies and should be used in the dependencyManagement section of your pom:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.richfaces</groupId>
<artifactId>richfaces-bom</artifactId>
<version>4.2.2.Final</version>
<type>pom</type>
</dependency>
</dependencies>
</dependencyManagement>
In the dependencies, you should have the implementation, like this:
<dependencies>
<dependency>
<groupId>org.richfaces.ui</groupId>
<artifactId>richfaces-components-ui</artifactId>
<!--version>4.2.2.Final</version-->
</dependency>
<dependency>
<groupId>org.richfaces.core</groupId>
<artifactId>richfaces-core-impl</artifactId>
<!--version>4.2.2.Final</version-->
</dependency>
<dependencies>
The version element of the dependencies is redundant, if you are using the bom. You are better off removing it, as you may unwillingly overrride the bom setting.
EDIT: the error you are getting looks like a configuration issue to me. Not sure what may have caused it. My advice is to start with a working webapp example and then add additional dependendcies. My favorite way is to let maven geneare a webapp from archetype:
mvn archetype:generate
you will then see a long list of possibl archetypes. Try something with a JSF in it, like jsf-weld-servlet-webapp or weld-jsf-jee or richfaces-archetype-simpleapp. These are known to work, and you can sample the pom and the rest of the project to see what may be missing.