Understanding Classloaders: log4j in a J2EE Environment
Subject:   You still haven't addressed the most important thing....
Date:   2003-04-17 07:53:07
From:   anonymous2
Response to: You still haven't addressed the most important thing....


This was a good topic to cover, thanks, classloading for J2EE is a constant source of troubles and frustrations and any clarifications are appreciated. I'd like to see a chapter or entire book written on the best way to organize classes in a J2EE app.

I must agree with the original point in this thread. Logging should be provided by J2EE as an app server service.

My recommendation would be to log using your own api (abstract factory pattern) which can then be implemented to use either the app severs logging capabilities, or log4j, or the jdk 1.4 logging. An example of why this would be useful would be log4j's own fickleness in it's api. First it was "Category" and now it's "Logger". It would be nice if they'd just make up their minds, but if you placed a protective layer between your app and logging implementation, you can update to the latest version by changing "category" to "logger" in one file.

BTW: What we need is logging that knows which class it's in without the developer having to specify it. Taking the classloading and that together, log4j is sometimes more trouble than it's worth.


1 to 1 of 1
1 to 1 of 1