I want to use Log4J into my application. I have a limited resources and I want to use just the basic part of Log4J. Can you tell which package I need to use just for basic logging.
P.S In order to use just basic Log4J which packages I can remove?
You need the first two, and if it's Maven-based build then only the second, Log4j Core and the first will be added as a transitive dependency.
You could also use this entry in pom.xml if you're using Maven or similar:
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.0-beta9</version>
</dependency>
Agree with Andrey, you need the core and the api jars. Note that the OSGi stuff is still a work in progress. About wich packages could be removed from the core jar: I see you also posted your question to the log4j mailing list. I'll answer there so that the whole log4j team can chip in.
Be aware though the the core jar contains config files in addition to .class files. If you rebuild a jar with a custom subset you must include those config files or the api will not recognize your jar as an implementation.
Related
I tried to run the sample code shown here but it's complaining that SLF4J is missing, so I downloaded the zip archive from the official website.
The tutorial video shows that 3 of the jar files are used (log4j-over-slf4j, slf4j-api & slf4j-log4j12) but if I add all 3 of them to the build path of my project (I'm not using Maven!), it complains that both "log4j-over..." and the api are there.
If I get rid of the "over" file, it says "Failed to instantiate SLF4J LoggerFactory".
So, which jar files do I need exactly to stop the complaints and run the sample code?
There is a tutorial showing all the dependencies needed for the sample code. Try this please: https://developers.itextpdf.com/content/itext-7-jump-start-tutorial/installing-itext-7
It basically gives you a list of the exact maven dependencies your project will need to run. You'll also find some indications how to make it work with the IDE like eclipse, netbeans and intelliJ
By using
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.7.18</version>
</dependency>
Edit:
you could manually download these 3 dependencies. They get any slf4j with log4j project going:
slf4j-api-1.6.1.jar
slf4j-log4j12-1.6.1.jar
log4j-1.2.16.jar
if you don't trust 3rd party site go the slf4j site and the log4j homepage.
We simply need the slf4j api, its log4j implementation and log4j itself.
Try removing log4j12. You cannot use both over and log4j12 at the same time. link
If you wish to use log4j 1.2.x as the logging back-end with slf4j, you need log4j-1.2.17.jar, slf4j-api-1.7.25.jar and slf4j-log4j12-1.7.25.jar.
I tried to run the sample code shown here but it's complaining that SLF4J is missing, so I downloaded the zip archive from the official website.
The tutorial video shows that 3 of the jar files are used (log4j-over-slf4j, slf4j-api & slf4j-log4j12) but if I add all 3 of them to the build path of my project (I'm not using Maven!), it complains that both "log4j-over..." and the api are there.
If I get rid of the "over" file, it says "Failed to instantiate SLF4J LoggerFactory".
So, which jar files do I need exactly to stop the complaints and run the sample code?
There is a tutorial showing all the dependencies needed for the sample code. Try this please: https://developers.itextpdf.com/content/itext-7-jump-start-tutorial/installing-itext-7
It basically gives you a list of the exact maven dependencies your project will need to run. You'll also find some indications how to make it work with the IDE like eclipse, netbeans and intelliJ
By using
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.7.18</version>
</dependency>
Edit:
you could manually download these 3 dependencies. They get any slf4j with log4j project going:
slf4j-api-1.6.1.jar
slf4j-log4j12-1.6.1.jar
log4j-1.2.16.jar
if you don't trust 3rd party site go the slf4j site and the log4j homepage.
We simply need the slf4j api, its log4j implementation and log4j itself.
Try removing log4j12. You cannot use both over and log4j12 at the same time. link
If you wish to use log4j 1.2.x as the logging back-end with slf4j, you need log4j-1.2.17.jar, slf4j-api-1.7.25.jar and slf4j-log4j12-1.7.25.jar.
I have a scenario as follows:
I am using maven as a build process. I am creating a web project in which I want to use a specific version of spring. This project also depends on a third party library which internally depends on different version of spring. I have a doubt that this will result two different versions of spring n class-path and unexpected behavior will be observed. I have few information which I wanted to get more clarification on.
Can I use maven BOM concept for this?
Can somebody explain with example how to achieve this?
Can somebody explain how do we make sure that third party wont behave abnormally if overall project depicts using a specific version using BOM?
If somebody can throw light on it and give a detailing reference, that would help me a lot.
Maven should know how to evict one or more of conflicting versions of an artifact.
However, you can influence that by simply excluding one of the transitively included dependency.
Example: the following code excludes the io.netty (transitive) dependency. In this way, you'd leave maven with the only other version as you decide/prefer.
<dependency>
<groupId>org.apache.hbase</groupId>
<artifactId>hbase-client</artifactId>
<version>${hbase.version}</version>
<!-- The exclusion below makes sure that this specific version imported by hbase does not end up deployed -->
<exclusions>
<exclusion>
<artifactId>netty</artifactId>
<groupId>io.netty</groupId>
</exclusion>
</exclusions>
</dependency>
Regarding runtime behavior, you have to test and decide for yourself (that is if you aren't lucky to have your direct artifact that documents versions of its own dependency)
You can use the concept of BOM but this won't avoid the conflicting issue of libraries by itself. It's very common that projects have one or more library which depends on the same other with different versions. In this case, when you want to force some specific library version for that third party library you must explicit it in your POM by using < exclusion > markups. This is not an easy task, once that projects usually have many libraries. So you need a tool to provide you an easy way to visualize a dependency hierarchy of your project libraries. There are some IDE plugins for this. Some versions of Eclipse, for example, have the maven plugin included in it, which provide a Dependency Hierarchy view ( a kind of dashborad of libraries and their dependencies ). Once you detected a library which should not using other library dependency ( wrong version for example ), you go at the this dependency in the pom and use the exclusion markup adjust the dependency version. Using the tool will make this task very simple.
I am planning to user Jackrabbit for developing an online document library.
To develop simple POCs, i have put the jackrabbit-standalone.jar inside my class path and everything works fine.
But on opening the jackrabbit-standalone.jar, i found out that it's a web project in itself.
I copied all the jars from jackrabbit-standalone.jar/WEB-INF/lib and kept in my class path and my project again works fine.
My concern here is that I don't want to keep any extra jars in my project. So my question is :
What are the minimal jars which are required to interact with
Jackrabbit repository?
What is the best way of using jackrabbit in a web project, as per enterprise standards. Is it using standalone jar in the class path or using only the required jars?
I won't ask why you want cut out unnecessary jars for a POC.
Do you use maven? If so, you just add jackrabbit-core and it will pull down dependencies.
If you require the JCR API you'll also need jackrabbit-spi2jcr.
Otherwise, this is what we end up with (version 2.6.4):
commons-collections-3.2.1.jar
commons-dbcp-1.3.jar
commons-pool-1.5.4.jar
concurrent-1.3.4.jar
jackrabbit-api-2.6.4.jar
jackrabbit-core-2.6.4.jar
jackrabbit-jcr-commons-2.6.4.jar
jackrabbit-spi-2.6.4.jar
jackrabbit-spi-commons-2.6.4.jar
jackrabbit-spi2jcr-2.6.4.jar
jcl-over-slf4j-1.6.4.jar
jcr-2.0.jar
log4j-1.2.16.jar
lucene-core-3.6.0.jar
slf4j-api-1.6.4.jar
slf4j-log4j12-1.6.4.jar
tika-core-1.3.jar
You can dispense with the logging jars if not needed. Not sure if you can get rid of lucene-core as I believe it's used internally.
Regarding how to use jackrabbit, that's entirely up to you. You can use it as standalone server or, like us, as your persistence layer. We use the JCR api.
you can use maven or gradle to manage dependencies for you.
If you are using maven, you can find out the dependency tree with command :
mvn dependency:tree
and review the relations between artifacts.
And you can exclude parts you don't want with exclude expressions:
<dependency>
<groupId>sample.ProjectA</groupId>
<artifactId>Project-A</artifactId>
<version>1.0</version>
<scope>compile</scope>
<exclusions>
<exclusion> <!-- declare the exclusion here -->
<groupId>sample.ProjectB</groupId>
<artifactId>Project-B</artifactId>
</exclusion>
</exclusions>
</dependency>
I'm new to maven and am converting a java web app to maven (instead of managed by my IDE). I understand that can install the dependency locally (first choice) or declare it as a provided dependency (second choice). I read about what groupId, artifactId, and version mean. However, it doesn't explain how to determine the exact coordinates of a jar.
The jar in question (servlet-api.jar of apache-tomcat 7.0.34) for example, doesn't have a pom.xml file in the jar.
When you have a random jar file, in this case servlet-api.jar, present in some folder, you have to poke around to figure out if it is the same as some version.
One:Look inside the jar and note the date (or date range) of the files inside it. You might notice what files are in there. You might need that detail.
Two: Go to somewhere that you can look for the jar. I like http://mvnrepository.com/ where you can type in the name of the jar. "servlet-api". I found this one in about 10 seconds:
<dependency>
<groupId>org.apache.tomcat</groupId>
<artifact>servlet-api</artifactId>
<version>6.0.36</version>
</dependency>
But its not yours. (Another 30 seconds and I found this: mvnrepository servlet-api for tomcat 7.0.34)
You can then download the one you think matches and look inside it to see if the date matches.
Its basically detective work from here. You might find the exact jar with maven 'coordinates' and you might not.
Reading the other answers reminded me that with the Java EE jars, I find it best to use a generic version for building your application. Use "provided" for the maven scope. The the container will provide the real jar and, if it isn't totally standard, you won't be using the non-standard parts because your build used the generic version.
So, for example, you might build with:
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.4</version>
<scope>provided</scope>
</dependency>
What I typically do is go to http://search.maven.org and look for the jars, for example: servlet-api.jar. You can also do fully qualified class name search, eg if you know inside your jar there is a class javax.servlet.http.HttpServletRequest, you can search for fc:javax.servlet.http.HttpServletRequest and it will list all jars containing this class
However keep in mind in the case of servlet-api.jar -- it shouldn't be bundled into your war/ears because it should be provided by container (tomcat in this case). Typically the best practice when creating Java EE project is to include dependency to javax.servlet:servlet-api:2.5 (or other version supported by you container) in provided scope. Hence the jars will only exist in your classpath during compile time, but at runtime it will be provided by the container
The Maven artifacts (JAR files) will be located in e.g.
~/.m2/repository/org/apache/tomcat/artifact/version/
The servlet-api.jar file will be located in ~/.m2/repository/javax/servlet/servlet-api/2.5/ if I remember correctly - given that you use version 2.5 of the servlet specification.
However, the servlet-api is always provided by the application container, hence the "provided" type of the dependency in the Maven POM.