********** Are JDK logging or Log4J ready for J2EE? See http://www.acelet.com/whitepaper/AreJdkLoggingOrLog4JReadyForJ2ee.html for html formated file.
JDK 1.4 (J2SE) introduces a new package java.util.logging. JDK 1.4 logging is a cousin of Log4J. Both of them are excellent logging systems in single JVM. In this article, we mainly discuss JDK logging. Most things, if not all, are applicable for Log4J as well. J2EE is a distributed computing environment. There are many machines working together. There is a clustering environment. The implementation of containers is not defined by J2EE specifications. So implementation of containers is different from vendor to vendor or from version to version. Even within one server instance, there may be many JVMs. Are JDK logging and Log4J ready for distributed computing environment? Are they ready for J2EE? No. JDK leaves a back door widely open for un-synchronized control of the system Let us use log threshold as an example to analyses the dangerous un-synchronized control. In JDK logging, both log require and log control code are within one class: java.util.logging.Logger. You use java.util.logging.log( ) to require log. You use java.util.logging.setLevel( ) to control log by setting log threshold. That is good in one JVM. This arrangement encourage programmers to control logging in application code. This is a very serious problem in distributed computing environment. When certain condition meets, setLevel( ) will be called in one component (EJB, JSP or helper class). The scope of that log threshold change is in one JVM. Other components in the clustering run in different JVMs. They do not know that change. All components are dynamically loaded in the cluster. We do not know which copy of which component runs on which JVM at a particular time. We only know that from that time on, they may use different log thresholds. If your application is developed in house, you may hire a logging police to discipline your developers not to control logging configuration in application code. But, if your libraries and components come from other source. It is impossible to do so. The problem is that there is no clear separation between log request (logging methods) and log control (management methods). The request of logging is invoked from application code. But logging behavior should be managed in a separated central program. This is out of J2SE design scope. JDK logging is an API, not a system The default persistent mechanism in JDK logging is file saving. This is prohibited by J2EE specification. You need to implement your own persistent mechanism. Although the API is standard, but the whole thing will not be standardized anymore. Recently Log4J published a built-in hook to use JMS as a centralized persistent logging mechanize. But asynchronized JMS as the mechanism is not the best choice. It can not guarantee log messages be chronological. There is no built-in mechanism to dynamically re-configure the log system keeping all parties in sync. It is difficult to implement too. There is a long way to go to build a standard logging system based on JDK logging. Other issues There are other issues too. For example, JDK logging API is not simple, there is a learning curve. When things are complicated, there will be chances to introduce logging bugs from application code. Performance is a concern too. But all other issues are minor ones comparing to the issued we discussed above. __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
