aspose file tools*
The moose likes IDEs, Version Control and other tools and the fly likes Initializing log4j within Eclipse on a per project (Dynamic Web Project) basis Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » IDEs, Version Control and other tools
Bookmark "Initializing log4j within Eclipse on a per project (Dynamic Web Project) basis" Watch "Initializing log4j within Eclipse on a per project (Dynamic Web Project) basis" New topic
Author

Initializing log4j within Eclipse on a per project (Dynamic Web Project) basis

Chet Hawkins
Greenhorn

Joined: Jun 15, 2011
Posts: 20
I am getting:

ERROR Could not parse file [log4j.xml].
java.io.FileNotFoundException: C:\eclipse4\eclipse\log4j.xml

My Dynamic Web Project uses a Tomcat server.
I have the log4j.xml file under my WEB-INF\classes folder as the log4j manual indicates.

My code snippet for the logger that produces this error:

// Logger
import org.apache.log4j.Logger;
import org.apache.log4j.xml.DOMConfigurator;
...
public class context
{

// Database
String driver;
String connectionURL;
String userId;
String password;
Connection connection;
// Logger
static Logger log;

public context(String driver, String connectionURL, String userId,
String password, Connection connection) {
super();
if (log == null) {
Logger.getLogger(context.class);
DOMConfigurator.configure("log4j.xml");
}


My observations and questions:

1) I do not understand why the DOMConfigurator ends up with the path "c:\eclipse4\eclipse\" in front of my log4j configuration filename.
2) The correct path before the filename would be "c:\eclipse4\workspace\RNR\WebContent\WEB-INF\classes\"
3) I have not modified the Tomcat startup as recommended because I want any such modifications to be Project-specific. When I say modified as recommended I mean to add something like this export CATALINA_OPTS="-Dlog4j.configuration=log4j.xml" somewhere in the Tomcat config/startup. The instructions I have assume that I am running Tomcat off the command line but I want to let Tomcat fire up inside Eclipse. I have no idea where to put the export statement (or if it will work when I do that).

Q: How do I configure log4j on a project by project basis ONLY within Eclipse and using Tomcat?

Any help is greatly appreciated.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16313
    
  23

Let me thrash about a little here and see if we can work something out.

The apparent cause of your primary problem is that you're using a relative pathname ("log4j.xml"). That can be - and in your case, probably is - perilous, since you're at the mercy of whatever last assigned a working directory to the thread. Normally, the recommended procedure would be to use an absolute pathname, but you're talking a webapp, so a better solution would be to use one of the servletcontext getResource/getResourceAsStream methods.

Why you're reading the log4j.xml manually instead of letting Log4j simply do the the initialization automatically, I'm not clear on, but then I tend to be pretty superficial when I read Ranch posts.


Customer surveys are for companies who didn't pay proper attention to begin with.
Chet Hawkins
Greenhorn

Joined: Jun 15, 2011
Posts: 20
Well, there are a number of examples talking about where you put the lo4j.xml file or the properties files (either one can be used). Regardless, when using Tomcat you have to explain to Tomcat where log4j is configured. Maybe I am overthinking as log4j is already a part of Tomcat (at least mine Tomcat v7.0.14). Still all the examples I see discuss setting that export inside the start/run shells for Tomcat. I am on Windows. There is a also a lot of discussion about configuring log4j that suggests the act of configuring it is piecemeal and leaves earlier configurations intact.

I am adding non additive appenders. My example uses the same syntax every example I have seen uses. I wanted a relative pathway because I want it to work in production and after deployment. Hopefully that makes sense. I am new to Java and Eclipse and the dev/build/deployment issues are not my forte anyway.

I tried using a non relative filename and the DOMConfigurator still appended the same pre-path. That seems flat wrong. The left me wondering why everyone seems to think log4j is the bestest, easiest logger to use ....

I'm fairly deep into it now.

I also considered defining the XML configuration file within a servlet. The example shown in the manual is for the properties file. I worry intuitively that using that example for an XML file will yield more seemingly random and incorrect results but that is my next shot.

Thanks for helping regardless!
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16313
    
  23

The log4j.xml/log4j.properties file must be at the root level of the classpath regardless of what type of java app/webapp/applet you're logging for. If you have both xml and properties, the xml file is the one that's used.

For J(2)EE webapps, the root of the classpath is WEB-INF/classes as well as the root directories of the jars in WEB-INF/lib. There's also classpaths inherited from the container, but let's leave well enough alone.

One of the confusing things about the Tomcat logging docs is that they don't actually mention that they apply only to the Tomcat server itself. Each deployed webapp manages its own logging and that is independent of the logging that Tomcat does for the Tomcat processes.

So just supply a WEB-INF/classes/log4j.xml file and Log4j will automatically pick it up and use it without any need for Java code on your part. Do bear in mind, however, that any files that log4j writes to should be specified as absolute paths, not relative filenames or you'll void the warranty.

If you want to pass in an external parameter to serve as the log directory root (for example), that would require you to write some log4j initialization code so that the path could be retrieved and applied to the log definitions. It's better to make the path be a JNDI-defined context parameter than to nail it to the Tomcat JVM.
Chet Hawkins
Greenhorn

Joined: Jun 15, 2011
Posts: 20
Also started considering XMLConfigurator instead of DOMConfigurator which some sources claim is obsolete. However, the log4j manual itself contains no reference to XMLConfigurator which seems scary to say the least. Par for the course ...
Chet Hawkins
Greenhorn

Joined: Jun 15, 2011
Posts: 20
Tim, Thanks for the help. I was able to find a working configuration as follows:

1) Your suggestions made me realize maybe I was overthinking it and so I removed the call to DOMConfigurator. Apparently I had the configuration file in the right place because my log file was picked up.
2) I had to address the static Logger declaration the right way as shown.
3) I confirmed the placement of a logfile as I configured it in my XML which points back to your earlier comment about a working directory.

This leaves me with this question I will research but any comments you have are welcome:

How do I set a working directory and if I set it can I anywhere near safely assume it will stay where I point it?


// Logger
import org.apache.log4j.Logger;

public class context
{

// Database
String driver;
String connectionURL;
String userId;
String password;
Connection connection;
// Logger
static Logger log = Logger.getLogger(context.class);

public context(String driver, String connectionURL, String userId,
String password, Connection connection) {
super();
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18997
    
    8

You can't set the working directory for Tomcat. Why would you want to do that anyway?
Chet Hawkins
Greenhorn

Joined: Jun 15, 2011
Posts: 20
I'm sorry I meant for my application/my logfile/ etc.

Currently, my logfile is being placed ... oddly ... is the best way I can describe it.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18997
    
    8

Those things don't have anything like "working directory". Choose a directory where you want your logs to go, and change your configuration to point to that directory. I don't understand why you are looking to finagle the environment so you don't have to do that.
Chet Hawkins
Greenhorn

Joined: Jun 15, 2011
Posts: 20
Didn't mean to cause confusion but that's what Greenhorns are good at.

The configuration file examples I have seen have only "blahblah.log" for the filename. I assume (no doubt incorrectly) that the filename is where I might modify its destination location (a horrible truth of all programming in general if you ask me (I know you didn't (just couldn't help myself))).

So, I guessed that the resultant logfile would be placed within my project somewhere or that of the Tomcat server. It wasn't is my guess. It was placed (along with many other logfiles) in the root of my eclipse install. Maybe that's where it goes by convention in this situation. I just didn't know. I'm learning a lot. But my problem is solved and TY for your input. On to the next 3742.2 issues!
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18997
    
    8

Yeah, seems like a lot of newbies were out of the room when the concept "current working directory of a process" was covered. Or (a lot more likely) it wasn't covered at all, just assumed to be basic information which everybody already knew.

Likewise the writers of tutorials don't feel the need to point out that not specifying the full path of a file name will lead to its being treated as relative to the process's current working directory; they just assume that's basic information which everybody already knows.

But obviously that isn't the case. Basic information? Yes. Everybody already knows it? Not so much.
Peter Johnson
author
Bartender

Joined: May 14, 2008
Posts: 5845
    
    7

Even within an application server or servlet container there is still a "current working directory". The only thing is that its location is not what you might think. For example, with JBoss AS, the current working directory is the jboss_home/bin directory. Why? Because that is the directory containing the run script that starts the app server. This actually makes sense - the current working directory is an artifact of the running JVM, and thus reflects the current directory when the JVM was started.


JBoss In Action
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: Initializing log4j within Eclipse on a per project (Dynamic Web Project) basis