in my Maven project I am using an external library (namely parallec.io) which uses LogBack as their logging framework and has logback.xml file packed into the JAR. I know it is considered a bad practice to pack logback.xml, but the developer somehow did it.
In fact, I need nothing of that wordy output (e.g. how it inicializes etc) so would be happy to disable logback at all. I am not very much into the logging thing, but I realized I need to create logback.xml and configure logging using it, but the problem is the conflicting file from the library. I tried this solution
http://www.mkyong.com/maven/maven-exclude-logback-xml-in-jar-file/
but it did change nothing as far as I can see.
So if some one could suggest me a quick way to just get read of logging (or at list exclude that default logback.xml) I'd really appreciate it.
Okay here's what I did, so thanks to px5x2 for the trick.
<dependency>
<groupId>io.parallec</groupId>
<artifactId>parallec-core</artifactId>
<version>0.9.1</version>
<exclusions>
<exclusion>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-core</artifactId>
</exclusion>
<exclusion>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
</exclusion>
</exclusions>
</dependency>
Related
I have a jar, say a.jar, for which I'd like to enable logging only at INFO level. This jar also depends on another jar, say b.jar, which uses Apache HTTP client. When I run my application, I see a lot of debug output on the screen including stuff from the Apache HTTP client in this format alone, irrespective of what I put in the log4j.properties:
[com.amazonaws.AmazonWebServiceClient] : Internal logging successfully configured to commons logger: true Ignored FQCN: org.apache.commons.logging.impl.SLF4JLocationAwareLog
For the life of me, I'm unable to figure out where the jars are getting their configuration from. Here're things I tried.
1. Added a log4j.properties to only a.jar's main/resources dir
2. Added a log4j.properties to only b.jar's main/resources dir
3. Removed log4j.properties
Please help me with some inputs as to where the logging configuration may be getting picked up from.
Here're pom extracts of a.jar
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.5</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.15</version>
<scope>compile</scope>
</dependency>
Here's the extract for b.jar
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.7</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.7.7</version>
<scope>compile</scope>
</dependency>
I assume that you mean this “Apache HTTP client”? If so, then your logging configuration for Log4J does not affect the log output of the HttpClient simply because the latter does neither use SLF4J nor Log4J. As you can see from this POM, HttpClient uses Apache Commons Logging for its log output instead.
So your goal is to redirect all Commons Logging output via SLF4J to Log4J. This requires two steps:
Add an SLF4J bridge for Commons Logging.
Make sure that the bridge is used as a replacement for Commons Logging.
The bridge to add is described here. To make sure that the bridge is actually used, I would recommend to exclude the original Commons Logging JAR. You should be able to achieve both steps with the following new/updated dependencies for your project B:
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
<version>4.5.3</version>
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<version>1.7.24</version>
</dependency>
I have added the jcl-over-slf4j bridge in the latest SLF4J version 1.7.24 since it seems that your version of SLF4J (1.7.7) doesn’t seem to support Commons Logging 1.2, yet, which might be used by the HttpClient (at least by the one in version 4.5.3).
(Note that I haven’t tested this. But the eventual solution should at least be pretty similar to the described approach.)
Looking at this, it seems like one of the amazon sdk jars is the place this logging configuration would be present in.
It uses apache commons logging and any configuration that you are doing in your project is being done for slf4j and hence is not taking any effect.
Let's consider this example
<groupId>com.abc.3rdparty</groupId>
<artifactId>abc-gsb-scala</artifactId>
<version>${GsbScalaVersion}</version>
<scope>provided</scope>
<exclusions>
<exclusion>
<groupId>com.abc.3rdparty</groupId>
<artifactId>safebrowsing2_2.9.1-0.2.5.jar</artifactId>
</exclusion>
</exclusions>
As I understand, <provided> means that the container will provide the jar right?
so what does <exclusion> means? that one of the jar within that will be provided by the project/application?
I am confused
Well, for your build, your hunch is correct, the exclusion won't do anything because it will be left out anyway. But if you're using an IDE that pulls in dependencies for you, this will exclude those transient dependencies while you develop. Make sense?
I am learning spring web mvc project from online resources, i came across this logger slf4j, and i want to use it in my application.
I don't have any idea on how to add this. what i am thinking is i should remove commons-logging.jar from lib folder, and add another jar file to lib folder, but then i don't know which jar file i should add as there are many jar files present in slf4j.zip that i have downloaded from its official site.
I have searched and read few posts/articles about integrating slf4j but they all were related to maven, and i don't have maven, i simply started working with adding spring framework jars to dynamic web project.
Please tell me how and what files i should add in lib folder for logging purpose. or how to configure the slf4j logger.
thanx folks!!
The official source of information on logging in Spring is the Spring Reference.
If you want to use SLF4J, this document suggests using the following Maven dependencies:
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>4.0.6.RELEASE</version>
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<version>1.5.8</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.5.8</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.5.8</version>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.14</version>
</dependency>
</dependencies>
In other words, you need four .jar files, and you need to make sure that the Commons Logging library is NOT on your classpath.
If you do not use Maven, you can download these .jars from the Maven Central Repository manually. Enter groupId, artifactId and version on that page, press Search, and download the .jar file (not sources.jar!). Here are direct links to these .jar files: jcl-over-slf4j, slf4j-api, slf4j-log4j12, log4j.
You will also need to create and put on your classpath the configuration file for log4j (log4j.xml or log4j.properties).
I think that by not using Maven you make your life harder, not easier. It's better to spend some time learning it, than spend a lot of time trying to avoid learning it.
I would actually argue against using pure SLF4J to begin with, because its own creators have already created a successor.
Reasons to use it instead of SLF4J are given on http://logback.qos.ch/reasonsToSwitch.html
And the "First baby steps" in the manual are at http://logback.qos.ch/manual/introduction.html
We have a solution where our UI projects are including quite a bunch of business services by using the EJB client dependencies. The problem with this on Maven is that even though the client .jar usually contains about 1-2 classes, they bring with them the full dependency stack of the entire service application. This can get a bit ugly, when the .ear files start growing up to 50-100Mb a pop and there are from time to time pesky errors thanks to irrelevant dependencies sneaking their way into the UI application.
Of course, we can always exclude the dependencies on the client end, but then we have to write the same bunch of lines to each client project using those services and that's a lot of needless repetition. Plus, people come up with the weirdest error messages and use a lot of time tracking them down before remembering to mention that they included some client jar and didn't check what additional dependencies it brought into the equation.
Example:
<dependency>
<groupId>fi.path.to.service</groupId>
<artifactId>customermanagement-common</artifactId>
<version>2.6</version>
</dependency>
<dependency>
<groupId>fi.path.to.service</groupId>
<artifactId>customermanagement-service</artifactId>
<classifier>client</classifier>
<exclusions>
<exclusion>
<groupId>fi.path.to.dependency</groupId>
<artifactId>internal-dependency-#1</artifactId>
</exclusion>
<exclusion>
<groupId>org.codehaus.castor</groupId>
<artifactId>castor</artifactId>
</exclusion>
<exclusion>
<groupId>fi.path.to.dependency</groupId>
<artifactId>internal-dependency-#2</artifactId>
</exclusion>
<exclusion>
<artifactId>internal-dependency-#3</artifactId>
<groupId>fi.path.to.dependency</groupId>
</exclusion>
<exclusion>
<artifactId>internal-dependency-#4</artifactId>
<groupId>fi.path.to.dependency</groupId>
</exclusion>
<exclusion>
<artifactId>internal-dependency-#5</artifactId>
<groupId>fi.path.to.dependency</groupId>
</exclusion>
<exclusion>
<artifactId>castor-xml</artifactId>
<groupId>org.codehaus.castor</groupId>
</exclusion>
<exclusion>
<artifactId>castor-codegen</artifactId>
<groupId>org.codehaus.castor</groupId>
</exclusion>
<exclusion>
<artifactId>castor-xml-schema</artifactId>
<groupId>org.codehaus.castor</groupId>
</exclusion>
<exclusion>
<artifactId>internal-dependency-#6</artifactId>
<groupId>fi.path.to.dependency</groupId>
</exclusion>
</exclusions>
<version>2.6</version>
</dependency>
That is just one service client being included, imagine having several of these in several different applications and you get the picture, writing up all the excludes each time is quite annoying and the project POMs start getting fairly longwinded.
I would mark the dependency as provided, but there are a couple dependencies that do crash on runtime, if they don't exist. Say ones that include another service call to yet another app with an external Exception class, which isn't for one reason or another wrapped inside the service project and will cause a ClassNotFoundException on runtime, if not present.
Therefore, I know it's possible to exclude/include classes from an ejb client during its generation through the usage of pom.xml specs on the maven-ejb-plugin, but is there any way to exclude dependencies as well?
Seems that Maven just doesn't support building multiple jars out of one module very well.
Thus the only reasonable way around this that we've found is to create another module (break xxx-service into xxx-service and xxx-service-client) and configure the xxx-service-client module to have only the EJB client/delegate class & minimal dependencies. That way the project can be built with a single execution.
I have the same problem here. I think one solution could be using profiles, since in each profile you could specify the dependencies (see http://blog.sonatype.com/people/2010/01/how-to-create-two-jars-from-one-project-and-why-you-shouldnt/)
In my case, this doesn't work, because I need to generate both JARs (ejb and ejb-client) in a single execution of Maven. :)
I'm getting the following error message:
java.lang.ClassCastException: weblogic.xml.jaxp.RegistryDocumentBuilderFactory cannot be cast to javax.xml.parsers.DocumentBuilderFactory
I've gone through some forums researching this. They said to remove xml-apis.jar or that JAR files were conflicting. But even though I did all the suggested steps, I'm getting the same error.
It's always the xml-apis.jar. Remove them from your classpath (e.g. remove them from WEB-INF/lib of your webapp).
Remove xml-beans-1.xb2 to the lib directory. Modified the POM so it does not include that jar file with the following:
<dependency>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
<version>1.0.b2</version>
<scope>provided</scope>
</dependency>
I think Banang is right. Forum http://forum.springsource.org/showthread.php?t=22597 describes solution for similar problem.
Typically such problems happen when there are several versions of the same class in class path while those versions are loaded by different class loaders. One version of DocumentBuilderFactory was loaded by system class loader, other by class loader of your enterprise application. When you are calling the XML parser the parent's version of the class is used. When you are casting yours private version is utilized. These versions are incompatible that causes ClassCastException.
The reason for this issue is you are having multiple jars with same class name in library.
Go to WEB-INF/lib and remove xml-apis-1.0.b2.jar and stax-api-1.0.1.jar or remove them from you pom.xml itself and you would be good to go.
I wanted make a slight addition to the previous answers to this question, in the event that anyone else is in the same situation I was. I had the same problem on our WebLogic 9.2 server due to my use of CXF 2.2.3. In addition to the removal of the xml-apis.jar mentioned previously, I also had to remove a xmlParserAPIs library.
As I am using Maven2 it was just a simple matter of adding another inclusion.
<!-- CXF -->
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-bundle</artifactId>
<version>${dependency.version.cxf}</version>
<scope>compile</scope>
<exclusions>
<exclusion>
<artifactId>xml-apis</artifactId>
<groupId>xml-apis</groupId>
</exclusion>
<exclusion>
<artifactId>xercesImpl</artifactId>
<groupId>xerces</groupId>
</exclusion>
<exclusion>
<artifactId>xmlbeans</artifactId>
<groupId>org.apache.xmlbeans</groupId>
</exclusion>
<exclusion>
<artifactId>xmlParserAPIs</artifactId>
<groupId>xerces</groupId>
</exclusion>
</exclusions>
</dependency>
Hope this helps someone!
We also has such trouble. The reason of error was in gwt library. Receipe: exlude all gwt client libraries from distr.
As for my case, I managed to solve this issue by removing xml-apis library and also upgrading an XML processing library:
From
org.apache.xmlbeans/xmlbeans/2.4.0
Into
org.apache.xmlbeans/xmlbeans/2.6.0
FYI, I'm using Weblogic 10.3.6.0.