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

Hi Taylor,

Thanks for the feedback.

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

You raise an interesting point. If you are familiar with the commons-logging package, then you would realise that what you have suggested has been already put into place by the wise men at Jakarta. It serves the exact purpose that you are referring to above.

" BTW: What we need is logging that knows which class it's in without the developer having to specify it. "

What you say here is a good idea. However, it is against the log4j's idea of flexibility. Loggers need not be specified on a per class basis. The whole idea of Logger naming is to let the developers use whatever logging nomenclature they think is best for them. If we restrict it to per class we are removing this flexibility. I have used a different naming convention in at least one previous project and found it quite useful. Further you may want more than one logger in your class to represent different types of logging. Having one Logger with the default name of the class would defeat the purpose.


1 to 2 of 2
1 to 2 of 2