There are lots of logging API choices for Java programmers today, but with so many choices, sometimes figuring out which one to use is a problem. What strengths and weaknesses do the APIs have, and what criteria do you use to figure out which API to work with? The most common choices are:

• Log4J
• Jakarta Commons-Logging
• SLF4J
• java.util.logging (AKA j.u.l)

There are others, of course, including logn and javolution, but those are rarely considered as first-line logging APIs. Log4J is the oldest of the logging APIs, and serves as the model for every logging system that has followed it. Commons-logging stands as a proxy for Log4J, as well as providing proxies for java.util.logging and Avalon's LogKit, which is now part of Apache Excalibur and itself can be a proxy to other logging systems. SLF4J is another, better stab at commons-logging's premise, with the addition of better classloader interoperability as well as varargs support for the loggers. java.util.logging is, of course, the JRE's standard logging facility, and is thus by definition always present - as long as your JRE is 1.4 or newer. All of the logging systems can map log calls to other logging systems, and the features differ only in small ways: namely, configuration and actual interfaces. SLF4J is the only one of these that supports varargs for 1.5 (although logn also supports MessageFormats), but that's the primary differentiator. So the questions stand: what is your analysis of the logging systems? Why did you choose the logging system you use? What criteria would you use for future choices? What features would you like to see in logging APIs?

Incidentally, in the interest of full disclosure, logn was written by Yours Truly and Dan North, from Thoughtworks.

You will choose NO LOGGING API. You do not need to hard-code log statements with open source LimpidLog at http://www.acelet.com/limpidlog/index.html. Also you do not need to read log files yourselves: LimpidDebugger at http://www.acelet.com/super/LimpidDebugger/ will read log files and interprets for you as a source code level debugger. Currently, LimpidLog is not stable yet. Version 2 just released fixing multi-thread issues. A stable version will be released soon, probably with different implementations for your to choose. Any contribution to LimpidLog will be appreciated. J2EE tools Wei Jiang

It is impossible to automatically generate logging. At least the kind of logging I put into my sources at debug level. These usually are lines that describe the reasoning that the program is following. It usually is also rather verbose, so it will save the person analysing the logging from having to interprete the code for every log line. For example: "Relation found for relationnr=12345, continuing to import the data" instead of "record found". Naturally info and higher levels are more to the point.

There are two (at least two) reasons for logging: 1. debug, 2. audit/record. Your reason for logging is audit/record. You want record something. It is impossible to automatically generate logging for audit/record, I agree with you. But, 90% of logging actually are for debug. 90% of volume of logging are from this category. 90% of issues come from this category. LimpidLog tries to address issues for this kind of logging. LimpidLog does not try to help logging for audit/record. But, LimpidLog can co-exist with logging for audit. You can log your data into data source of LimpidLog, or your own data source. J2EE tools Wei Jiang

There are two (at least two) reasons for logging: 1. debug, 2. audit/record. Your reason for logging is audit/record. You want record something. It is impossible to automatically generate logging for audit/record, I agree with you.

But, 90% of logging actually are for debug. 90% of volume of logging are from this category. 90% of issues come from this category. LimpidLog tries to address issues for this kind of logging. LimpidLog does not try to help logging for audit/record. But, LimpidLog can co-exist with logging for audit. You can log your data into data source of LimpidLog, or your own data source.

J2EE tools
Wei Jiang

Bullshit, most logging should not be for debug, I have found that most explicit debug logging are a waste of time, unless you need very detailed trace information, even then, debug level logging will often be disable in normal live situations. The majority of logging should be info logging to say when you are doing an important major step (also for audit/record), lesser steps will often be revealed by warning log and error log stack traces for exceptions (with sensible error messages!), even if you have to add more descriptive chained exception. The Java core libraries have some really useless exceptions which don't say what and which value failed, so I often have to add a more descriptive chained exception, for logging purposes.

This is quite a hard topic to answer just because every single logging framework has both it's pros & cons. Really the correct choice depends on: * What you are already used to? * What your team/co-programmers are used to? * What level of flexibility do you require? * Can a framework support what you require out of the box? In my experience most of these questions have been answered by using a combination of commons-logging and log4j. That said the front end facade could have been served by commons-logging or SFL4J and the backend could have been JDK logger, logback (http://logback.qos.ch/) or whatever. The most important thing I would do when using logging systems is to choose a logging facade just because it gives you a certain amount of flexibility to change logging implementation if you suddenly find your original choice to be flawed. In practice I've never had to change logging implementation and any deficiencies in logging have been my fault & a mis-understanding of how to configure logging frameworks more than something fundamentally wrong in the loggers.

I would be happy with log4j if only it had var-arg support.

It becomes very difficult to understand log messages in a multiuser application. Does any logging api has inbuilt support for thread local based logging with time stamp? That would be very much readable.

It becomes very difficult to understand log messages in a multiuser application. Does any logging api has inbuilt support for thread local based logging with time stamp? That would be very much readable.

Log4J does, with NDC, and so does SLF4J. j.u.l can also support it.

It becomes very difficult to understand log messages in a multiuser application. Does any logging api has inbuilt support for thread local based logging with time stamp? That would be very much readable.

Log4J does, with NDC, and so does SLF4J. j.u.l can also support it.

I've been thinking about logging for some time now, enough to start coding yet another open source logging framework for you guys ) At this point I have only checked in some prototype code. Sorry, no good web page and no releases yet... only raw sources, but enough to demonstrate the point. I called it qb4j, pronounced Why is it sometimes difficult to analyze your data - there could be only two reasons for this. 1 you don't have all the information in the cube 2 you are using wrong tools to access the cube... What is cube? Cube is the OLAP term for a multidimensional matrix. OLAP stands for Online Analytical Processing. One way to think of it is a big sparse multidimensional matrix, where each dimension is a hierarchy. Sounds abstract, but that what they are using to analyze data in business world. You know why? Because it is THE BEST way to analyze data. And that what we need our log files for, right? We want to analyze them. Not the flat file should be the end product of the logging mechanism, but the OLAP cube that you can query. Those dimensions and hierarchies are familiar in Java. You just need to think about the log record as a data on the intersection of multiple hierarchies, here they are Time Dimension Log record ----------- Year___________________________2009 _Month________________________ Apr __Hour_________________________4 ___Minute______________________21 ____Second_____________________3 _____Nanosecond________________325 Threads Dimension ------------ Domain___________________qb4j.sourceforge.net _Computer________________name:vasya-pc1 _________________________ip:192.168.0.1 ___Process_________________main class: net.sf.Sample ___________________________started: 2009 Apr 4:20:2:1032 ___________________________arguments: String[]:{} _____Thread_________________ main _____________________________isAlive: yes _____________________________isDaemon: no Exceptions Dimension ------------- Library _Lib-Version __Package ___Class ____Exception Developers Dimension (who wrote the line of code in the class) -------------- Department ________________Engineering/Essbase __Developer ________________Vasya Pupkin ____________________________title: Software Engineer ____________________________manager: Peter Z. Hopkin Methods Dimension (method being executed) ----------------- Library________________myproject _Lib-Version________________1.2 ___Package________________com.myproject.utils ____ Class_________________MyHashMap _______Method_______________MyHashMap(String, String) ____________________________args: name="x", val="y" _____Line_______________________33: this.map=new HashMap(); Users Dimension (os user that initiated the action) ---------------- User_____________________________vasya-pc1\vasya Values Dimension [Local Variables] (our values) ---------------- Library __Lib-Version ___Package _____Class ________Instance Object ___________Method ______________Variable Values Dimension [Object and static class properties] ---------------- Library__________________________myproject _Lib-Version_____________________1.2 __Package________________________com.myproject.utils ___Class_________________________MyHashMap ____Instance_Object______________MyHashMap(1) _____Property____________________map _________________________________old_val:_null _________________________________new_val:_HashMap() You should start seeing by now how each level in each dimension has its own information and how comprehensive the log record becomes? Now we have it in source control, right? Yet another dimension SVC Dimension --------------- SVN_rep_____https://qb4j.svn.sourceforge.net/svnroot/qb4j _dir_________________________src/com/myproject __file_______________________MyHashMap.java ___revision__________________4 ____line_____________________33 The most often missed dimension! Configuration Dimension --------------------- All Properties _System.getProperties()_______{"classpath=blabla...",_""} _log4j.properties_____________{"logger.bla.level=DEBUG",...} ... And let's put it inside a servlet, so you have another dimension of users - your web users Web Users Dimension -------------------- Realm________________________tomcat _User________________________manager And web requests Web Requests Dimension --------------------- Session______________HttpSessionImpl_ _____________________started:_10Jan2009_10:10am _Request________________HttpRequestImpl ________________________urlparams=reply.jsp?message_id=12 ________________________ip=192.168.1.10 Remember - the right column is just one big log record... And all of this happens at the same time, in our case it was somebody who has logged in to the web server from 192.168.1.10, sent a request and that caused invocation of a method that changes some values and is written by some developer in some thread at the certain time. Our log record is data on the intersection of all of those hierarchical dimensions. To get the cube I think the new Logger mechanism should: 1. Each logged value should have an indication of where it is in the hierarchy 2. Should automatically figure out an efficient way to store log records. I am not familiar with all the frameworks, but I don't know any single one that does this. With log4j you should think how to normalize your data in the loggers so you not logging the same information about the process for each log record 3. Should provide some OLAP interface to use with analytical tools. (usually SQL-like language called MDX) Please read more about OLAP to better understand what I am talking about here. Hope we will soon have all the analytical information we need at our fingertips!

Just thought about one more very useful dimension for the "log cube". Extracted from the source code and placed into the cube.. Explanation Dimension ------------------ Explanation __/*Comments*/____________author:Vasya Pupkin __________________________text: /*slicing and dicing the analytical cube*/" __//TODO__________________author:Vasya Pupkin __________________________text:"//todo need to think of a better way to analyze my log files" This way you can have a nice google-finance like view of your thread's runtime with your comments popping out as news articles. Interactive analytical applications could be created using Oracle/Hyperion Interactive Reporting, it is built to work with Oracle/Hyperion Essbase, the Oracle's multidimensional version of the database. It allows you to perform drill-through operations on the cubes using your mouse, you don't need to know MDX to slice and dice your cube. There is another thought I find very exciting - there is a star-tup in California, http://replaysolutions.com that does the "DVR for software". If you have the DVR you can create something I would call 'THE PERFECT CUBE'. In which you have ALL THE INFORMATION THERE IS. I imagine that querying the perfect cube could replace debugging in most cases.

http://qb4j.sourceforge.net The fist open-source multidimensional logging framework. Meanwhile, if you need help in adopting multidimensional logging principles in your project, please write me an email mailto:cube.logs@gmail.com

What's that? Can you provide a (brief) example?

When you log a sequence of steps in a multi-user application, the log messages of that sequence becomes discontinuous when simultaneous requests are made. For example, a log message like this: -Method1 started at 12:30:00 by user1 with "data" --Method1.1 started at 12:30:01 by user1 with "data" --Method1.1 ended at 12:30:02 by user1 with "data" -Method1 ended at 12:30:05 by user1 with "data" would become: -Method1 started at 12:30:00 by user1 with "data" --Method1.1 started at 12:30:01 by user1 with "data" -Method1 started at 12:30:02 by user2 with "data" --Method1.1 ended at 12:30:02 by user1 with "data" --Method1.1 started at 12:30:04 by user2 with "data" -Method1 ended at 12:30:05 by user1 with "data" --Method1.1 ended at 12:30:06 by user2 with "data" -Method1 ended at 12:30:09 by user2 with "data" This is difficult to read/debug in a production environment. So a logging API could accumulate the log messages of a thread in a thread local variable and print them as a continuous log at the end of a thread execution without memory leak. But looks like this feature is very much there (in fact much better) in most of the API. Should thank joe for pointing it out.

So a logging API could accumulate the log messages of a thread in a thread local variable and ...

The problem with this is that you get no output to the log in cases where things die. You might be able to program around this in most cases but there will always be some way to lose the contents of that thread local. The second problem is that some thread run for a long time andy you may want to monitor the progress. If nothing is printed until its done, you don't see the partial results. The way you solve this is by thinking of your log output as a file that is sorted by time. That's the normal way it comes out. You can sort it by thread and then time if you want. That shows what you want to see

The problem with all the discussion about isDebugEnabled() is that the example is a special, though common, case. In the general case there is a bunch of computing that has to be done to prepare the debugging message. In the special case cited, there is a string concatenation comprising the "bunch of computing" which, depending on what you are doing, may not really matter at all. What if you had to go read something off a CD ROM drive before printing the debug message and that takes 2 seconds. Your code would need to be be: if (log.isDebugEnabled()) { String msg = readStuffFromCD(operationType); log.debug("Operation: " + operationType + " - " + msg); } Variable arguments isn't going to solve that problem. (Plus, passing variable arguments to the method takes longer than passing a single String anyway.) I'd be interested to see how the "other" loggers handle this situation.

if (log.isDebugEnabled()) {
String msg = readStuffFromCD(operationType);
log.debug("Operation: " + operationType + " - " + msg);
}
At this point wrappers like slf4j are handy where you could write log.debug("Operation: {} - {}", operationType, readStuffFromCD(operationType)); I'm not saying its good (easily readable) code but in this case expressions are not evaluated before real logging. And in my opinion varargs is not that necessary feature. Most of the time argument count is below two. While reading these comments I'm starting to think that maybe logging really needs a new innovative approach.

I would dearly like to see some valid reasons for logging the way we do today. In my opinion developers log for many different reasons which to me indicates we are probably abusing this generic interface and mechanism and instead look to introduce more specific interfaces. Why using logging for tracing when we could have a Trace interface? Why use logging for resource metering when we could use a Probes interface that fully supports the concepts involved in monitoring/metering (Probe, Meter, Metering, Reading)? Why use logging for problem diagnostics when we could use a Diagnostics interface that fully supports the concepts (Frames, Variable, State). I have been planning on proposing one or more JSR's to address these short comings so that we can have a consistent interface that better address runtime monitoring concerns better than logging and JMX in a more user friendly and optimized manner. The Interface21 team and other enterprise software vendors (including our competitors) have been interested in our open Diagnostics API which does unofficial have a SPI. Maybe we could band together so that we could reduce the duplicate effort of many developers creating their own AOP + tracing + diagnostics +.... solution. Then we could compete on the underlying performance of the implementation as well as on tooling (analytics). regards, William Louth JXInsight Product Architect JINSPIRED "Performance Management and Problem Diagnostics for Java EE, SOA, and Grid Computing" http://www.jinspired.com

I agree with William. I think there are two scenarios for logging: 1) A framework 2) A final product A final product should have some kind of (configurable) logging because is "closed", but what about frameworks? A framework is a tool designed to be used as a layer below your program. There are tons of internal states and tasks to log something, what log? why?. I think the listener approach is better, the framework can offer interesting hooks about what is doing (before and/or after the task), this approach is more interesting because it offers interception points of the program normal flow, the developer can do anything, including business logic and of course ... logging. I think a wrong use of logging is to provide it as a "debugging tool" (the worst debugging tool). For instance: think about your favorite ORM, I would like to see what SQL is using under the hood, logging? NO, some kind of listener with a context parameter with info about the SQL being to be used, nice for logging, and if this SQL sentence can be replaced, absolutely nice because the same listener provided mainly for logging may be used as a filter to enrich the SQL control (for instance to add an ORDER BY). Jose M. Arranz Innowhere

I think the listener approach is better, the framework can offer interesting hooks about what is doing (before and/or after the task), this approach is more interesting because it offers interception points of the program normal flow, the developer can do anything, including business logic and of course ... logging.

I agree, this is because I am thinking about using LimpidLog for this.

Personally I don't have too much opinion on any of these solutions. What bugs the crap out of me is the fact that there *are* so many solutions in the first place. To be sure, one of Java's best features is the plethora of 3rd party libraries to use in your own applications... but this is silly. I don't think I'll ever forgive Sun for not just adopting Log4J as the 'standard' logging interface for the JVM. If they had done that, three of the four listed choices be a single choice.

I don't think I'll ever forgive Sun for not just adopting Log4J as the 'standard' logging interface for the JVM. If they had done that, three of the four listed choices be a single choice.

I totally agree, Log4J worked (and still works) just fine, why did they both to write an inferior version? Varargs support would be nice but it's a small price to pay. Log4J and System.err.println(""); rule! -John-

This is a good topic. We use a loging system that is similar to Logn. The main problem we have found is that all of the main logging systems are geared toward developers. They are bound to class names and the like. We use the masking system the Logn uses and thus have many more log event types. This means that we can have startup and shutdown messages that go to one log and fatal errors go to all logs. Further, we have audit, playback and even can mask a log by the current user id. Finally, we currently have 28 different log event types and each message can be masked to one or more of them with each appender listenning based on a subset of Event Types, userid, and/or system id. This gives us a single enterprise logging and auditing system for all 7 of my clients current java systems. I would recomend a closer look at Logn for everyone. Hope the docs get better on it.

System.out.println(...) ;-)

Use java.util.logging for your application code logging. Configure java.util.logging to delegate to whatever the best logging implementation of the day is. Done.

Yup, I agree basically with this meme. Essentially, commons logging should die, and be replaced by j.u.l. j.u.l is as flexible and as extensible as any of them -- what distinguishes a logging framework nowadays is essentially sugar as they could all be hammered and layered to provide any interface you like on either end. Now, the extensibility of j.u.l may not be as evident as others, and some may balk at the default interface (again, sugar), but it's all in there. Giving it a proper SPI isn't mandatory nor crippling one way or another, as the mechanism is there to change it (albeit not as elegant as the SPI). But j.u.l is there on all modern JVMs and I think it would behoove us culturally to using it as a "commons logging" and then season to taste the back end as desired. Commons logging is "de facto", but j.u.l is "de rigeur". It would be nice to see some instruction and codeon the log4j site (say) plug log4j in as the back end for j.u.l to get the ball rolling.

+1 just use j.u.l I hate all of these different logging systems and then trying to use this and that framework all using a different logging system. +1 to get some improvements into j.u.l but it gets most of what you really need done.

Lobby for a JSR to finally improve the java.util.logging API and give it a proper service provider interface so that in the future the only real question is which SPI implementation to use, not which API to use.

SLF4j + LogBack really rocks !

Anything that eliminates isDebugEnabled() gets my vote. Thank god for LogBack !!!

Anything that eliminates

isDebugEnabled()

gets my vote.

Thank god for LogBack !!!

Then I need to disappoint you: isDebugEnabled() cannot be eliminated. (You may omit it, but it would cost you time.) Basically it is there to save your string operations, or other processing. Consider: log.debug("variable : " + var ); You need to create a new string instance regardless the state of you channel. This is what you are saving with isDebugEnabled(). It is not mandatory to you, it is your best interest. A simple log line 'log.debug("Some message");' would not need any 'if' condition, unless you have more than one calls. Cheers, Tamas

Maybe you can't eliminate it. But you can surely hide it. That's what Blammo is doing.

Isn't this the reason why ObjectRenderer exists?

Then I need to disappoint you:
isDebugEnabled() cannot be eliminated. (You may omit it, but it would cost you time.)
Basically it is there to save your string operations, or other processing.
Consider:

log.debug("variable : " + var );

You need to create a new string instance regardless the state of you channel. This is what you are saving with isDebugEnabled().

What about in this case? log.debug("this is the error #0", var); this is from Seams logging.

Folks, this isn't rocket science! public void log(Level level, String msg, Throwable thrown, Object[] args) { if (logger.isLoggable(level)) { if (args != null) { msg = MessageFormat.format(msg, args); } if (thrown != null) { logger.log(level, msg, thrown); } else { logger.log(level, msg); } } } public void debug(String msg, Object... args) { log(Level.FINE, msg, null, args); } public void debug(String msg, Throwable thrown, Object... args) { log(Level.FINE, msg, thrown, args); } log.debug("Hey -> this {0}, that {1}, other {2}", this, that, other); Trivial wrapper on top of j.u.l. Feel free to write your OWN trivial wrapper on top of your favorite API.

Your example is pretty close to optimal. With Project Flogger, there's a flogger created per level and most every method is some variant of "log( ... )" method. So log.debug( ... ) becomes DEBUG.log( ... ). The log message template in your example is modeled after java.text.MessageFormat. Project Flogger uses the JDK 1.5's printf functionality. So your usage snippet would look like this when using Project Flogger: DEBUG.log("Hey -> this %s, that %s, other %s", this, that, other); (Assuming each parameter is a String instance.) A major pitfall with merely wrapping another logging API is that your code still incurs the runtime overhead even when logging is disabled. By using JDK 1.5's printf and varargs, Project Flogger mostly eliminates that overhead. Project Flogger was unleashed on the world just a few days ago. So there's no open source goodness yet (e.g. generated javadocs, unit tests). But it works fine. The jar contains a runnable Example, to show how to get up and running quickly.

Surely if you are going to using logging for debugging would it not be much more efficient and sensible to use an API that actually mimic the runtime execution behavior. I wonder how many people would be productive using a code debugger that spewed out strings "this x, that xx, other xxx" and ignored concepts such as frames, named variables and values which are lost in the logging translation. What's worse logging (1) kills the performance of most applications, (2) is subject to software bugs (wrong message or incomprehensible language), (3) overloads a back end storage with 90% of useless data, (4) and reduces the state model (vars) to primitive types of stringified memento, (5) pushes the data rather than allow it to be pulled when required. We need a proper diagnostics interface that does not require someone to write a native agentlib just to debug an application and affords a higher level of abstraction for concepts not representative in languages (transactions, workflows). Check out the following links and see why logging is wrong in such circumstances. JXInsight Diagnostics Open API http://blog.jinspired.com/?p=35 Diagnostics Tags http://blog.jinspired.com/?p=52 Component State in Diagnostics Global Frame http://blog.jinspired.com/?p=44 Diagnostics API http://www.jinspired.com/products/jxinsight/api/ By the way who does consider the addition of entering(...) and exiting(...) methods to the Logger good interface design. Have we really surrendered the asylum to the lunatics? From my experience the people that do log excessively have not got a clue what they are doing. Logging is indicative of their lack of understanding of the system and/or confidence in its execution. regards, William

This is my traditional, and possibly obsolete, means of doing logging: /*-DEBUG-*/if (log.isDebugOn()) log.debug("msg: "+msg); The comment at the beginning offsets the log statement from "real" code, and with syntax highlighting helps remove it from perception once you get used to it. The comment also provides an easy means for regex processing of the source files in case we want to mass comment/remove the statements. Calling isdebugon bypasses the concat for non-debug levels. Meaningful debug statements will double as comments as well, and make log reading much simpler. (auto-loggers fail tremendously in this respect). Log storage should not be an issue in the age of $110/500GB. Granted "enterprise" storage is more expensive, but come on. It isn't 1990 anymore. Youre first example (didn't bother past that) doesn't really help things, it looks like the amount of "source pollution" from setup calls to your API will be about the same scale. I doubt your apis magically solve the overinformation aspect beyond what sensible filtering tools could do to a traditional logging api. Both messages I've read of yours do a broad-based criticism of logging in general without any appreciation of what it does do, and then shills your product and api as the magic bullet. Right.

Youre first example (didn't bother past that) doesn't really help things, it looks like the amount of "source pollution" from setup calls to your API will be about the same scale.

A classic posting even by TSS standards. TTS posters always seem to comment on things they know nothing about. If you had looked past the first article which by the way is used to introduce diagnostics runtime concepts via the API then you would have realized that in fact the APIs are instrumented into the code base via various extensions including AspectJ, Proxy, JBoss AOP, Spring, ServletFilters, CORBA Portable Interceptors..... The API and diagnostics runtime are completely separate from the instrumentation likewise the application management console is not dependent on our particular underlying Diagnostics SPI implementation.

I doubt your apis magically solve the overinformation aspect

How can you even say this when you have not even bothered spending any time looking further into my proposal?

sensible filtering tools could do to a traditional logging api.

Great, filtering of a flatland were the half of the context (object structure) is lost because a toString() or primitive formatter is called. Do you think a truly developer understands the type of data that might be relevant at every execution point and even if you did why would you want a developer acting as a "sensible" filter which would be the case? Objects (and state) don't lie, developers can and do. For your information diagnostic dumps include object runtime field state graph (to a configurable depth) of target objects, thread objects, arguments and exceptions as well as a large amount of class meta data including code sources, class loaders, and configuration. Today to instrument a codebase with diagnostics requires the creation of an aop.xml placed in a jar under META-INF and placed the class path of the runtime which is instrumented with our JavaAgent and AspectJ loadtime weaver. You can then take snapshots of requests in flight or when an error is detected and store them for offline analysis. JXInsight 5.5 and AspectJ - Sample Application http://blog.jinspired.com/?p=132 A little bit of IT management experience would help in understanding that the cost is not in the hardware unit itself but in its management and inefficient usage in performing root cause analysis for problems in production. William

Both messages I've read of yours do a broad-based criticism of logging in general without any appreciation of what it does do, and then shills your product and api as the magic bullet.

I never said that. I pointed out that the generic logging interface is abused and that more specialized interfaces built into the Java runtime would be better both in terms of ease of use, efficiency of the implementation, extensibility and tooling. Logger.entering() and Logger.existing() just so unnatural especially when people are mainly using these for timing execution blocks. Personally I would have preferred for the Logger API's to be more complex event processing (CEP) oriented with built into support for aggregation events over various contexts (time, transaction, session..). But maybe then it would be best to have a Events API and leave Logger to those who simply want to write a string to some back end storage. Apps. The (Apple) developer will see you now. http://www.apple.com/macosx/leopard/developer/xray.html JXInsight has had the above for many years now within in its timeline analysis views. But I suppose you must be innovative in both the design of a product and its market acceptance (re-education). regards, William

Surely if you are going to using logging for debugging would it not be much more efficient and sensible to use an API that actually mimic the runtime execution behavior.

Isn't that what a profiling tool does? I looked at JXInsight's online info. Looks cool. But I'm not sure that I want to manually instrument my code. Use case wise, how does JXInsight differ from alternatives like DTrace, JProbe, etc?

You do not need to manually instrument your code. JXInsight 5.1 comes with standard instrumentation for Java EE components accessed via JNDI. We also have many extensions for other middleware technologies such as JBoss Interceptors, CORBA Interceptors, Spring AOP..... JXInsight 5.5 makes this incredibly easy by coming with a powerful set of AspectJ library extensions that require you to simply drop a extension library into the classpath of your JVM. For each technology we ship a Trace, Probes, Diagnostics, Diagnostics Dump and Diagnostic Observer extension library. You pick want level of monitoring you require for each particular technology. This article explains this in more detail. http://blog.jinspired.com/?page_id=104 The following article listing provided additional information regarding our AOP runtime support. I hope you will agree that JXInsight is the first tool that makes this technology usable and extensible in an enterprise context. http://blog.jinspired.com/?cat=38 Please note that our aspects and all other custom extensions work on the same public API that we offer to customers and partners. http://www.jinspired.com/products/jxinsight/api/ We plan on introducing new API's for Metrics and Events as well as a revised Traces interface for improved performance and ease of integration. The biggest difference (and there are many others) is that JXInsight makes it possible to see the software and system execution model via powerful visualizations and automated analysis inspections. regards, William Louth JXInsight Product Architect CTO, JINSPIRED "Performance Management and Problem Diagnostics for Java EE, SOA and Grid Computing" http://www.jinspired.com

All I see is advert for a commercial monitoring framework to make you rich with license and support fees. I will only believe you have genuine intentions for a JCP when I see a free OSS version on a reputable repository. I also do not see this costly? monitoring framework as a replacement for a proper logging system, with carefully designed logging messages and custom logging helper classes.

You do not need to manually instrument your code. JXInsight 5.1 comes with standard instrumentation for Java EE components accessed via JNDI. We also have many extensions for other middleware technologies such as JBoss Interceptors, CORBA Interceptors, Spring AOP.....

JXInsight 5.5 makes this incredibly easy by coming with a powerful set of AspectJ library extensions that require you to simply drop a extension library into the classpath of your JVM. For each technology we ship a Trace, Probes, Diagnostics, Diagnostics Dump and Diagnostic Observer extension library. You pick want level of monitoring you require for each particular technology.

This article explains this in more detail.
http://blog.jinspired.com/?page_id=104

The following article listing provided additional information regarding our AOP runtime support. I hope you will agree that JXInsight is the first tool that makes this technology usable and extensible in an enterprise context.
http://blog.jinspired.com/?cat=38

Please note that our aspects and all other custom extensions work on the same public API that we offer to customers and partners.
http://www.jinspired.com/products/jxinsight/api/

We plan on introducing new API's for Metrics and Events as well as a revised Traces interface for improved performance and ease of integration.

The biggest difference (and there are many others) is that JXInsight makes it possible to see the software and system execution model via powerful visualizations and automated analysis inspections.

regards,

William Louth
JXInsight Product Architect
CTO, JINSPIRED

"Performance Management and Problem Diagnostics for Java EE, SOA and Grid Computing"
http://www.jinspired.com

"Rich with license and support fees". Wow. Obviously you have never started and ran your own software business in this day and age. What is really funny is that nearly every good OSS product or project depending on were you are standing is making money from license and support fees. No VC gives a OSS based company 5 or 10 million USD unless they are going to get "rich with license and support fees" from those developers you fail to grasp the obvious but I suppose that is why they are engineers. For your information I did run this by at least two other OSS vendors at the TSS conference last year in Las Vegas. I needed some backing before putting forward a proposal. Unfortunately they felt such a standardization would weaken their position because it would possibly allow a commercial vendor with a superior implementation and supporting tool to kick them out of sites were they had gained some traction via their distribution model. This is a fact and clearly shows what is the underlying (but not necessarily bad) motive behind a lot of OSS - business growth. Just to recap as I do think you have missed the whole point in all my postings on this thread which was that logging should NOT be used as debugger interface, runtime diagnostics framework or performance monitoring solution. These still need to be addressed with less generic log recording interfaces. regards, William

What about in this case? log.debug("this is the error #0", var);

this is from Seams logging.

This works for the simple case (which is the most prevalent one). But imagine log.debug("this is the error #0", var.loadDetailsFromDB()) or even log.debug("this is the error #0", MessageFormatter.formatAsXml(var.getSubTreeList())). Rare, but necessary for those "once-in-a-month" cases, where you need to log as much as possible.

Bostjan Dolenc writes:

This works for the simple case .... But imagine log.debug("this is the error #0", var.loadDetailsFromDB()) or even log.debug("this is the error #0", MessageFormatter.formatAsXml(var.getSubTreeList())). Rare, but necessary for those "once-in-a-month" cases, where you need to log as much as possible.

Correct. Project Flogger's strategy is to call toString() on the object instance passed in only if debugging is enabled. To illustrate, here's a code snippet from Flogger's most simple log method: public void log( Object message ) { if( disabled() ) return; if( message != null ) { message = message.toString(); } getTopic().log( this, null, (String) message ); } Which, alas, doesn't help with the examples you provided. Perhaps using a functor (design pattern) is appropriate. Or refactoring everything to use the toString() method. Or a combination. Ideas will be warmly received.

Project Flogger eliminates the need for isDebugEnabled(), controllable per level, by a) using JDK 1.5's varargs and printf and b) inverting the instance and method signatures (for lack of a better way to describe it). So "log.debug(...)" becomes "debug.log(...)".

Project Flogger eliminates the need for isDebugEnabled(), controllable per level, by

a) using JDK 1.5's varargs and printf and

b) inverting the instance and method signatures (for lack of a better way to describe it).

So "log.debug(...)" becomes "debug.log(...)".

does this imply that debug.log("hello, value of x is: "+x); wouldn't eval the string concat? I'm pretty sure it does eval it. Unless there is a flow control structure (if then or ?:) the concat will occur, unless sun added something new to the lang.

Anything that eliminates

isDebugEnabled()

gets my vote.

Thank god for LogBack !!!

Then I need to disappoint you:
isDebugEnabled() cannot be eliminated. (You may omit it, but it would cost you time.)
Basically it is there to save your string operations, or other processing.
Consider:

log.debug("variable : " + var );

You need to create a new string instance regardless the state of you channel. This is what you are saving with isDebugEnabled().

It is not mandatory to you, it is your best interest.

A simple log line 'log.debug("Some message");' would not need any 'if' condition, unless you have more than one
calls.

Cheers,

Tamas

That's what makes the j.u.l implementation so pointless and maddening. Thanks for giving us an inferior api to log4j AND not providing any language features/JVM features to make it easier.

Blammo also eliminates isDebugEnabled(). It does so by preventing you from using the low level logging APIs altogether. This is how it works: * You write your own high-level logging interface, specific for the conditions that you expect * Blammo generates an implementation of that class. * This implementation calls an adapter for the low-level logging API you prefer. (Whatever you like.) * The adapter will do the is(Debug/Fatal/Warn)Enabled() call and call back on the generated implementation to generate the message, when required.

Anything that eliminates

isDebugEnabled()

gets my vote.

Thank god for LogBack !!!

The elimination of "isDebugEnabled()" is why varargs is so important for logging. While isDebugEnabled() *can* be more efficient, varargs can eliminate the need to build strings during the call.

All, I would also recommend to have a look at Blammo (http://blammo.sourceforge.net/) Here are some of its features: * Define your own high-level specific type-safe logging API vs. using a low level general purpose logging API * Get a documented message catalog for free * Reduce the number of if (log.isDebugEnabled()) statements in your code * Be able to test your logging code easily * Plug in your own behavior easily * Start coding before configuring your logging framework If you are interested, I suggest you check out these entries: http://agilejava.com/blog/?p=94 http://blogs.sun.com/wilfred/entry/blammo_logging All criticism is welcome. If you think this doesn't work, just tell me so. (BTW, the central Maven repository will have the Blammo libraries available soon.)

We have way too many frameworks in Java and this is just one more example. There is no need for 4+ logging frameworks. This just adds needless decisions and inconsistencies to projects.

This may be a bold statement, but with Blammo you could have classes that don't have *any* static dependencies on something else, and still have logging. Blammo allows you just to define listener interfaces for events that might happen, and - if you want - make Blammo implement those interface, and have them injected into your class with your favorite IoC framework. This is valid Blammo Code: public class DaRealThing { private DaRealThingLogger logger; public void doIt(int value) { // Uh oh, mayhem having to do with the value parameter logger.logMayhemHappened(value); } } public interface DaRealThingLogger { void logMayhemHappened(int value); } Again, Blammo makes it possible to turn this into logging for any kind of low-level logging API, but it doesn't enforce it. I guess this is what it means to implement to an interface, instead of an implementation.

I didn't realize that Java was dying? What's next then? SLF4J gets my vote.

A couple weeks ago, I got a chance to look at the source code of log4j. If your logging configure only defines the log level to the 3rd level of your package hierarchy; a logging call from a class deep in the package hierarchy is expensive; it needs a FOR loop to iterate through the hierarchy up to find the EffectiveLevel. I like the older implement better, even though it was less flexible. Does anyone know how's the j.u.l implemented? Harry

Project Flogger is still very new. So this announcement is a bit premature. But with this method thread, it seems timely. Project Flogger - Simple logging API which sucks less. Replaces log4j, JDK logging, Commons Logging, and SimpleLog?. Flogger has many attractive features:

• Zero overhead when logging is disabled.
• Unlimited levels.
• Leverages JDK 1.5's language features (printf and varargs).
• Simple configuration.
• Dynamic (runtime) configuration.
• Lazy initialization.

The current effort is make this Project Flogger ready for public consumption. It works fine. Just download the jar and run the example. But all the open source goodness hasn't been created yet (e.g. HOWTO, javadoc, etc.).

If log4j adds vararg support which can be used to avoid isDebugEnabled method by moving this check to the log4j code just before concatenating the args will make log4j the best choice.

SLF4J is another, better stab at commons-logging's premise, with the addition of better classloader interoperability as well as varargs support for the loggers.

Are you sure slf4j supports varargs?? Apparently not: http://www.slf4j.org/api/org/slf4j/Logger.html

Are you sure slf4j supports varargs?? Apparently not:

Presumably because they want to also support pre-1.5, they;ve gone with a variation. SLF4J has functions for log("log this {}", arg) and log("log this {} and {}", arg1, arg2) but for more than two, you need to pass an Object array, i.e. log("log this {}, {} and {}", new Object[] { arg1, arg2, arg3}). In practice, it's fine - I guess my IDE would warn me if I did try to pass 3 args, but it's not happened yet. Anyway, for small apps, I'll use https://simple-log.dev.java.net/, but for more convoluted requirements, I've used log4j in the past (and agree that Sun's not taking it onboard was a big mistake) but now I'm tending to use slf4j & log4j, although I should probably be looking at logback rather than the latter.

End of 2007, and the J2EE community is seriously spending 51 posts arguing what logging API to use. Groundhog day for 8 years...

End of 2007, and the J2EE community is seriously spending 51 posts arguing what logging API to use.

Groundhog day for 8 years...

Yes, that's an appropriate analogy for using log4j et al. In the movie Groundhog Day, the protagonist had a few lessons to learn before the next day could occur.

Hi, For me the major drawback of logging is the risk to raise exception with logging arguments (mostly null pointer exception). like logger.debug(nullObject.someattribute); Is there a mean to avoid this effect (except for testing null values or try catch around the logging ) ? Thanks Thierry

Here's an option if you're looking for a Java 5 wrapper for slf4j:

 

http://usna86-techbits.blogspot.com/2012/08/introducing-slf4j5-logging-varargs.html