Hi all, I have been researching on J2EE and Logging before I start with Logging and it seems to me we have issues there What I want to do ------------------ 1. I have multiple apps and I would like to host them as combination of EJBModule+Webapps instead of creating one J2EE application. I don't have any strong reason to follow this but this way it would be cleaner I guess so, I have like, EJBModule1 + Webapps1, EJBModule2 + Webapps2 , ... ... ... EJBModuleN + WebappsN NOw, I want to have logs of each EJBModule<<i>>+Webapps<<i>> go to a different log file, <<some application id>>.log. Also, I am looking for that RollOver logs functionality so I don't end up having a huge file...Hence I would have something like, EJBMod1LogDate1.log, EJBMod1LogDate2.log, ... EJBMod1LogDateN.log
EJBMod2LogDate1.log, EJBMod2LogDate2.log, ... EJBMod2LogDateM.log you know...
Now, followings are my observation+issues, ISSUES ------- 1. We can't use Java 1.4 logging as the configuration would be per JVM and within each application under one JVM we can't change configurations via the config file 2. We can use JMS for logging but that would be probably overkill for me 3. I can use URL resource (via J2EE Connectors) but again what if those connections fail and all..who logs them? I less prefer it and put it as last choice probably... 4. People go with Commons-logging+Log4J but I guess I would just go with Log4J directly...but are there any issues with Log4J with J2EE Logging?
What would be a good way to come out with this logging architecture for me? any thoughts would be appreciated... Regards Maulin
I'd suggest you go with using JMS -- this is, by the way, built into Log4J with the JMS Appender. That makes it pretty easy. The major advantage of JMS is not only that you can pick and choose which combinations to log to each topic/queue (simply by adjusting your configuration information for each one) but that you can also choose to have clustered applications (running on multiple machines) logged to a single shared topic/queue -- which can be very helpful. Kyle
Hi Kyle, Thanks for your input. Do you have any good points against JDK1.4 other than, 1. its not pluggable really and 2. we don't have something like- RollingFileAppender in Log4J? Please let me know. I can't really decide I don't see myself doing severe/heavy logging.... Regards Maulin
Maulin, Here is a table that I pulled out of a book that I am currently authoring. Because of formatting issues, I am presenting them below as a List. 1. Simple Console, Socket, File Logging (JDK Logging - Yes, Log4J - Yes) 2. Multiple Log destination support � SysLog, NT Event Log, JMS Channel (JDK Logging - No, Log4J - Yes) 3. Comprehensive File rotation by date, size etc. (JDK Logging - No, Log4J - Yes) 4. Logging Format (Layout) Support (JDK Logging - No, Log4J - Yes) 5. Logging with Diagnostic Context (JDK Logging - No, Log4J - Yes) 6. Configuration Format (JDK Logging - Properties, Log4J - Properties, XML) 7. System property based Initialization (File or class as a system property) (JDK Logging - Yes, Log4J - Yes) 8. J2EE Affinity [By setting a system property, all the web applications in a JVM are affected. However, since you can bundle Log4J in your web application, it is local and change in configuration does not affect system wide) (JDK Logging - Less, Log4J - More) 9. JMX MBeans (JDK Logging - No, Log4J - Yes) Apart from the pros you mentioned, 5, 8 and 9 are really what turns the table in favor of Log4J. No matter, how less (or more) logging you have, you need a Nested Diagnostic Context support. Otherwise logging from multiple users get mixed up. J2EE affinity is very important when hosting multitude of departmental/enterprise apps on app server farms. And then JMX Mbeans support to turn on/off logging in production environments is critical when you are in dire straits and seeing some critical error in production and want to turn on logging without stopping the app server. Hope this helps. For more information: The chapter on logging in my book is almost ready. It will be posted for public review at http://www.theserverside.com in a week.
Maulin, You can easily extend the JDK1.4 logging system, and define your own appenders (called "handlers" in JDK1.4). I've written a small JMS handler which can log to a queue or topic. If you decide on the JMS route, let me know if you want to use it (no doubt there are a few others floating on Google.) You'd have to decide what to do with the log once it is sent to its destination. Also, the FileHandler in JDK1.4 is equivalent to log4j's RollingFileAppender. You can specify the max file size by specifying the java.util.logging.FileHandler.limit property, and the number of files to keep around with the "count" property. -Ade Barkah
This has been posted a while back, but I had the similar issue a while back and found that clusterlog.net met my requirements for nice and easy logging in J2EE Webapplications. Since it supports log4j and logback, we didn't even have to change any code.