Women in Technology

Hear us Roar



Article:
  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....

Vikram,


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



Full Threads Newest First

Showing messages 1 through 3 of 3.

  • You still haven't addressed the most important thing....
    2003-04-17 20:29:02  gvix [View]

    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.

    Regards,
    Vikram

    • You still haven't addressed the most important thing....
      2004-11-08 16:07:23  new_one [View]

      Hi Vikram
      I am not sure if this related to the above msg.
      I see a problem where log4j is logging into log files randomly . means it writes couple of
      lines and suddenly it over-writes on previous entries.

      is it because of multiple JVM's or mulitple processes or

      can it happen in single JVM or single process.

      is it thread safe?

      How it fix this scenario

      thanks
      kumar
    • Event Logging useing LOG4J
      2005-08-05 06:38:41  S.SINGH [View]

      Hi Vikram,
      From Architecture point of view what could be the best practices to Log4J. What are diffrent norms we should follow to acheive architectural goal (Performance /scaling, etc)

      How Log4j (Appender)writes event messages to a log file ? It collects certain meessage in buffer and then write in one I/O ?? or For every even log it make one I/O ??
      How we can minimise the I/O calss ??

      Regards,
      SS