tags:

views:

644

answers:

5

I have some jar files that will be distributed to clients that are using log4j for logging. My question is should I include a log4j.xml configuration in the jar file or have the client provide one if they want logging?

My feeling is to leave the log4j.xml configuration file out of the client jars, since the apache jar files all come with log4j logging, but sans log4j.xml.

A: 

If you are using log4j in your application then you include it in your project. If you are not, then why would you put it in there? What if client A wants log4j version 1.2 and client B wants log4j version 1.3.

Let them decide what they need for their projects and worry about what you need for yours.

amischiefr
You are probably referring to the actual log4j.jar dependancy, but I am talking about the configuration file log4j.xml.
Mike Pone
Ahh yes, sorry I missed that. I have a project here that has a dependency for this ABIS jar file. This ABIS jar file has it's own log4j.xml configuration file. My log4j parameters are sometimes overwritten by the ones from the imported ABIS jar (logging level set to ERROR instead of the DEBUG I have mine set at). I would definitely leave it out and let the client set theirs.
amischiefr
+8  A: 

Yes, leave it out. It's an utter nuisance when your log4j configuration file is ignored because one of the 60 third-party libraries of your app contains its own.

mfx
+4  A: 

The good thing about log4j in your case is that your jar really shouldn't have to worry about it. The basic use case of log4j is:

  1. Obtain a logger object for the current class
  2. Call one of the methods on that logger, such as debug("some message");

If the jars you are shipping are to be used by a larger application, then ideally your code will only do the two steps listed above. In this way, your code will simply obtain logger objects from the already-configured log4j instance in the client's application. Your production code is then decoupled from having to know how to configure log4j.

Any logging you need to see for your development of the jars can be accomplished by configuring a log4j instance in unit test setUp() methods or something similar that won't get bundled with the production code going to the client.

alt_tab
A: 

I would add the configuration xml and load it up with instruction for the user showing different configuration and options. This will make it easier for either them or support to enable addition logging.

Javamann
this forces the client to edit the contents of my jar file. Not sure I call that a best practice.
Mike Pone
+2  A: 

I would put a default log4j configuration that you expect will be useful to your clients in the documentation. This way interested people can see what logging options you have (usually certain classes have more interesting log messages, from the user's perspective). I find it annoying when I have a third-party lib using log4j and it has no documentation, and there are log messages filling my screen and I have to try to figure out how to enable or suppress certain log messages.

Mr. Shiny and New