Article:		Understanding Classloaders: log4j in a J2EE Environment
Subject:		You still haven't addressed the most important thing....
Date:		2003-04-04 10:11:58
From:		anonymous2
Which hardly anybody addresses - which is how to use it in a cluster. What's the point in explaining how to do it on a single server. I guess the main reason nobody tells how to do it is because log4j is an infant - it has no cluster support. Far better to stuff log4j away until it becomes mature, and use WEbLogic's superior logging.

Showing messages 1 through 7 of 7.

• You still haven't addressed the most important thing....
  2003-04-11 05:09:34  gvix [View]
  
  
  Hello,
  
  Thanks for the feedback.
  
  The articles main idea was to understand classloading issues and not act as a manual for all the issues involved in J2EE packaging and deployment.
  
  I agree that log4j in a cluster is an issue. However, it can be addressed by using either SocketAppender or JMX.
  
  I disagree when you say that log4j is not mature. There needs to be more to substantiate that claim than lack of genuine cluster support.
  
  Regards,
  Vikram Goyal
• 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
• log4j in a cluster is an issue?
  2003-04-21 21:55:18  gvix [View]
  
  
  Hi Darryl,
  
  Log4J in a cluster is an issue if you are using FileAppender. The problem arises because of multiple process from multiple machines writing to the same file. Either you need to synchronize these processes by writing a buffer around the FileAppender or use some other appender like the SocketAppender or the JMSAppender.
  
  Best Regards,
  Vikram Goyal
• You still haven't addressed the most important thing....
  2003-04-17 07:53:07  anonymous2 [View]
  
  
  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
  
  
  
• 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
  
  
• 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
• 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