Firstly, not sure if this is the correct sub-forum (or even correct forum) for this question, so sorry to any mod/admin if it needs moved.

OK, background on my situation. I'm writing an application and trying to use SLF4J 1.5.8 (with Log4J 1.2) for application logging. I am packaging my application (including all appropriate libraries) into a Fat Jar file and running it from the command line with the standard "java -jar <filename>". Now, that goes perfectly well if I include the "log4j.properties" file for Log4J in the jar file, but what I'd like to do is to keep the properties file outside of the jar file (so I can edit it without having to rebuild the jar) and also have several differently named configuration files which I can load when I initialise my application (the filename for the configuration I want to load being kept in a configuration file I can edit). This is not going so well. What I have tried to do is to user the System.setProperty() method to force Log4J to use the specific class (in the main method of my application before the logger is used) as such:

System.setProperty("log4j.configuration", log4JPropertiesFile.getAbsolutePath());

However, this doesn't appear to work because when I run my application I get the following warning:

log4j:WARN No appenders could be found for logger (examplepackage.Example).
log4j:WARN Please initialize the log4j system properly.

Can I accomplish what I want to, and if so how?

Secondly I have another problem related to the configuration of the properties file itself. I want to specify the file name for the log file with a relative path (e.g. just put the filename in there and for it to be written in the same directory where my jar file is being executed from), but everything I've seen in examples etc has shown that you need to specify the full path in the properties file. This isn't hugely convenient if you move the application for whatever reason. Is there a way to just specify a the log filename and have the log written in the folder the jar is executing from?

Hopefully you can help me out here before I pull all my hair out!

Edited by: amp88 on Nov 2, 2009 1:50 PM

 

 

Silly question, I'm sure, but you do have the SLF4J-lo4j library on the classpath don't you?

 

 

I haven't set the class path but I shouldn't need to as all of the libraries are included inside the Fat Jar file. I think if there was a problem locating any of the classes in SLF4J/Log4J I would get a no class definition exception and the application would fall over into a heap rather than running but giving a warning about the configuration. The application functions perfectly well without the logging, I just want it there for obvious reasons. Thanks for the suggestion though :)

 

 

Another silly question:

log4JPropertiesFile.getAbsolutePath()

This does return the path to the properties file, doesn't it?

 

 

Yes, it returns the correct path (I've manually checked it in Windows Explorer and I have a .exists() check within my code to make sure the file is there). There's no such thing as a silly question! :)

Edited by: amp88 on Nov 2, 2009 3:01 PM

 

 

Try not using Fat Jar for the moment - or at all, really, it sucks - to eliminate it from the problem.

 

 

Not true. Logging facades such as SLF4J and commons-logging are quite happy to start up without having anything to delegate logging to. The fact that you didn't just say "yes it's there" makes me suspect it isn't. Check that.

 

 

If I just export the JAR normally in eclipse (i.e. without the libraries included) then attempt to run the application I do get a ClassNotFoundException for SLF4J:

Exception in thread "main" java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory

I want to try to get this working by using a single JAR file as I'm setting it as my codebase path for my application (it's an RMI app).

 

 

Well you will do. You still need to provide the jars to the classpath, one way or another.


There's nothing you've said so far that means you have to deploy your code as a single jar. Most software beyond the most trivial, uses some sort of dynamic linking, be that dlls or jars or shared objects or whatever. It makes things easier.

 

 

The point I was trying to make about the NoClassDef was that the libraries were correctly set on the classpath in the Fat Jar (otherwise the app would fall over as I said before).

 

 

No. What you've proven is that your code, alone, in an ordinary jar, won't work as it has dependencies on, at least, the SLF4J API, and probably others. The point I was making was that your application will still run happily if SLF4J is missing the adapter for log4j.

edit: you are aware that there are three libraries involved in using SLF4J, right? The SLF4J API, the delegate framework, and the SLF4J adapter.

Edited by: georgemc on Nov 3, 2009 7:00 PM

 

 

OK, I take your point.

I've now exported a normal JAR with eclipse (i.e. without the libraries) and added those libraries to the manifest so the manifest now looks like this:

Manifest-Version: 1.0
Main-Class: examplepackage.ExampleMain
Class-Path: libraries/derby.jar libraries/google-collect-1.0-rc3.jar libraries/log4j-1.2.15.jar libraries/slf4j-api-1.5.8.jar libraries/slf4j-log4j12-1.5.8.jar
 

I've taken the Properties.setProperty() call out for the log4j properties and I've just put the "log4j.properties" (i.e. default name, should be picked up) file in the same dir as the new JAR file. What am I missing here?

 

 

How are you starting the jar? Where are those dependencies? Personally, I don't rely on specifying the classpath in the manifest, I prefer explicitly setting the classpath as arguments to the JRE. That eliminates a lot of classpath issues.

 

 

Starting with:

java -jar Myjarfile.jar

from command line.

The directory where the jar file I'm running is contains another directory called libraries and that contains all of the lib jar files.

Edited by: amp88 on Nov 3, 2009 12:01 PM

 

 

Ignore

Edited by: amp88 on Nov 3, 2009 12:35 PM