All inline Juan Pablo Lorandi Chief Software Architect Code Foundry Ltd. [EMAIL PROTECTED]
Barberstown, Straffan, Co. Kildare, Ireland. Tel: +353-1-6012050 Fax: +353-1-6012051 Mobile: +353-86-2157900 www.codefoundry.com > -----Original Message----- > From: A mailing list for Enterprise JavaBeans development > [mailto:[EMAIL PROTECTED]] On Behalf Of Wei Jiang > Sent: Wednesday, July 17, 2002 9:32 PM > To: [EMAIL PROTECTED] > Subject: Are JDK logging or Log4J ready for J2EE? > > > ********** 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. Yes. Log4J works. I'm using it. I'm using it as we speak. > > 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. I refer you to the packages java.security AND java.security.acl. They've been part of the JDK since release 1.2, which is the worst-case scenario requirement for J2EE. They allow you to control which programs can control log threshold. That, without even mentioning that Log4J is open-source. > > 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. It can be managed separatedly. > > 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. Their socket listener implementation can very much do so. They're timestamped at the origin point, and you may optionally restamp them at the central server. The logging level may also be managed at the central server. > > There is no built-in mechanism to dynamically re-configure > the log system keeping all parties in sync. It is difficult > to implement too. That's true for any syncronization mechanism; it makes more sense to have a central log machine and to filter there. > > There is a long way to go to build a standard logging system > based on JDK logging. I respectfully disagree. Just minor glitches a couple of helper classes and reading manuals thorougly. > > 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. Sample code to instantiate a logger in a class: private static org.apache.log4j.Category log = org.apache.log4j.Category.getInstance(MYEJB.class); And use it: try { ... } catch (CreateException ce) { log.error("Couldn't create a MYEJBDep entity", ce); } Don't look like rocket science to me. My 2c, Juan Pablo Lorandi Chief Software Architect Code Foundry Ltd. [EMAIL PROTECTED] Barberstown, Straffan, Co. Kildare, Ireland. Tel: +353-1-6012050 Fax: +353-1-6012051 Mobile: +353-86-2157900 www.codefoundry.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".
