| Article: |
Understanding Classloaders: log4j in a J2EE Environment | |
| Subject: | You still haven't addressed the most important thing.... | |
| Date: | 2003-04-11 05:09:34 | |
| From: | gvix | |
|
Response to: You still haven't addressed the most important thing....
|
||
|
Hello,
|
||
Showing messages 1 through 2 of 2.
-
You still haven't addressed the most important thing....
2003-04-17 07:53:07 anonymous2 [View]
-
log4j in a cluster is an issue?
2003-04-18 11:10:45 anonymous2 [View]
Hello Vikram,
I have enjoyed both of your articles. I am new to log4j and researching it for use across my company's applications.
We are running WebLogic clustered, so I am wondering what you mean when you say "I agree that log4j in a cluster is an issue"? What are the issues related to clustering??
Thanks,
- darryl



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.
Taylor