Maven uses slf4j, so as soon as it is launched, it initializes it with its default implementation contained into apache-maven-3.3.9\lib\slf4j-simple-1.7.5.jar and with configuration file defined in apache-maven-3.3.9\conf\logging\simplelogger.properties.
After that it loads the pom file and found my jetty-maven-plugin which launch a webapp. But in this webapp I want to use a different implementation for slf4j, but I can't because slf4j is already initialized.
I understand that maven is mainly a tool for build and not to launch apps, but I can't modify log configuration of apache-maven for each project to get pretty logs for each of them.
Is someone already face this issue and find a way to avoid that?
Note:
run-forked instead run works but in this case I can't no more debug from eclipse so I prefer an another solution.
older version of maven works as 3.0.3 because it didn't used slf4j
Related
I am doing JPA without persistence.xml (without Spring Boot) and instead used the PersistenceUnitInfo to create the entity manager. When running the application from my IDE, there are no errors, but it logs sensitive persistence unit information. I've struggled to disable the logging.
It gets worse, when I run it from the command line, I get the following:
Kindly assist, I've lost quite a few hours to this one.
The issue you encounter is a classloading issue during initialization of your EntityManager on your JBoss application environement.
Disabling the logging will not fix this error, but hide it. Check your deployment classpath, and your JDK version. And verify that all required hibernate libraries are present. You can check which libraries you need on the classpath by looking at the dependencies on a site such as mvnRepository (example: https://mvnrepository.com/artifact/org.hibernate.orm/hibernate-core/6.0.2.Final).
Are you using a dependency manager, such as Maven or Gradle?
What I am trying to do is to configure the logging implementation used by maven.
(i.e. mvn itself, not the project being built/tested).
I know that I can do this by dropping logback jars into $MAVEN_HOME/libexec/lib and dropping logback.xml into $MAVEN_HOME/confi/logging, but I would like to know whether there is a declarative way to do this, which doesn't involve physically copying jars.
I had the impression that this kind of thing might be possible using maven profiles but this seems like something which would need to be set before the mvn process is even started.
Let's say we build a Java SDK and different projects can consume by adding it as a jar in the classpath or adding it as a dependency in the maven pom.xml or gradle file. Logs from the SDK are not visible at run-time when the other projects are consuming this library. I tried with SL4J, and none of the logs are visible at the run time when it is used by the other projects. Should I go with log4j2? If yes, should I provide with a log4j configuration /properties file in my SDK? Will the properties/configuration be picked-up at run time from the consumer libraries? What are the best practices for this? Can you please advise?
Best practice #1: never include the logging configuration file in your jar.
Applications using your library will likely want to provide their own logging configuration. If one of the jars contains a different configuration it becomes a “fun” guessing game for these applications to figure out why their configuration isn’t working. (And depending on the classpath order, their configuration may sometimes take precedence over the configuration in the library, so sometimes it will work, just to make it extra challenging...)
I've got a Java Eclipse/Gradle multiproject build build that uses SLF4J/Logback in the client, server, and a couple of libraries. I cannot figure out how to manage my Logback configurations in a way that permits sane Junit4 testing without generating the error
Resource [logback-test.xml] occurs multiple times on the classpath.
My configuration files look like this:
project
server
config/logback-dev.xml
src/main/resources/logback.xml
src/test/resources/logback-test.xml
client
config/logback-dev.xml
src/main/resources/logback.xml
src/test/resources/logback-test.xml
library
src/test/resources/logback-test.xml
Production config logback.xml for each distribution module goes in src/main/resources. It gets added to the build, and ends up in the jar. This seems necessary, because Logback's database appender is part of the application, and I need a default log configuration that includes it.
Development config logback-dev.xml lives in module/config. I specify its location as a VM argument in eclipse: -Dlogback.configurationFile=config/logback-dev.xml
In theory, my unit tests should all use logback-test.xml, which should live in module/src/test/resources for each module.
It's that last point that's the problem. Running a Junit4 test on a module with dependencies will pick up it's src/test/resources/logback-test.xml... but will also pick up the logback-test.xml that eclipse has placed in the module/bin of each dependency. Logback gets loaded before JUnit runs any user code, so programmatic solutions won't work.
I have dozens of Junit4 classes that I want to run in Eclipse. I'd rather not get stuck manually specifying VM args for each of several dozen Junit run configurations in Eclipse.
How can I avoid the multple logback.xmls error for my unit tests without manually configuring every JUnit class?
I'm working in a multi module maven eap project. Previously it was implemented to use slf4j to use as logging framework. I changed it's logging configuration to use log4j2 as the underlying logging framework (still uses the slf4j). I referred to this document when I do so. But when I build the project and deploy it in jboss I get the following error.
Class path contains multiple SLF4J bindings, Found binding in xxx/lib/log4j-slf4j-impl-2.0.2.jar/org/slf4j/impl/StaticLoggerBinder.class and xxx/lib/slf4j-log4j12-1.7.2.jar/org/slf4j/impl/StaticLoggerBinder.class
P.S: I never add the slf4j-log4j12-1.7.2.jar dependency to pom.xml or in any of sub modules. I have no idea how that dependency is copied in to the lib folder.
Any comments guys ?
Well as it says it means you have indeed several slf4j bindings in your project.
You are right to deal with it now as it can become nasty and hide logs.
You should run
mvn dependency:tree
to see which of your modules adds the dependency to slf4j-log4j12-1.7.2.jar. It is probably that you have a transitive dependency to it.
You problem has in fact several solutions:
you can exclude slf4j-log4j explicitely
you can use the "provided" scope
you can use empty artifacts
I am referring to the following FAQ. It is about excluding commons-logging, but should be the same for you with slf4j-log4j.
When I ran into the same kind of problems, I found solution 2 to be the easiest to set and maintain. But solution 3 should work fine as well.