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 Wayne King > Sent: Thursday, July 18, 2002 12:42 PM > To: [EMAIL PROTECTED] > Subject: Re: Are JDK logging or Log4J ready for J2EE? > > > >> ********** Are JDK logging or Log4J ready for J2EE? > >> > >> See > >> > http://www.acelet.com/whitepaper/AreJdkLoggingOrLog4JReadyForJ2ee.htm > >> l > >> 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. > > > How do you dynamically configure (log level, filter...) it > in a clustering environment? I set log level to max, then filter at the server. I have a socket listening for log events; I've extended SocketNode a little to re-timestamp, but filtering capabilities are built in. It is somehow trivial since Log4J is open source. I just add the server(central logger) timestamp to the message. I also tend to think this could be made more cleanly at an Appender, but call me too lazy ;-) It is arguable that any class may set log level to max in an OOB configuration; you can circunvent that using policytool. In fact, unless you use policytool, there is no way to assure that it won't happen. Again, since Log4J is open source, you can circunvent that. > > > > >> > >> 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. > > > > > If you try the following program: > > class t { > public static void main(String[] args) throws Exception { > long[] time = new long[10000]; > for (int i = 0; i < time.length; i++) > time[i] = System.currentTimeMillis(); > > for (int i = 0; i < time.length; i++) > System.out.println(i + ": " + time[i]); > } > } > > > You will find "timestamped at the origin point" is not good > enough. Do not forget that the resolution of network clock > synchronization will not be better than 10 milliseconds. Yes, that's why I re-timestamp at the SocketNode(and I had to create my own, copy-pasting from Log4J original code). Usually, even if the clocks aren't synchronized, it is trackable for me since I host Web Server and App Server in the same JVM; if that wasn't the case, I'd have to rely on the server timestamps and it would be messier to track. Also, I resent that the original poster didn't at least place the <vendor/> tags or by any other means disclosed this is an article by a company that sells their own logging solution. This is very rude manners for this forum, and I have never expected such a behavior from a technical party (I can understand why headhunters sometime miss this, and I feel more tolerant towards it). I also dislike lots when a marketing campaign is based on talking bad of the competition. In the paper there are a lot of bold statements(nothing against that, I do that here all the time) but the fact that this seems like a warm up to a sales pitch aimed at we subscribers to purchase Super from ACElet affects the paper's credibility. My 2c(this time I'm sure it's flame bait, but wadda heck, _somebody_ had to say it), 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".
