Log4j 1.2, the open source logging toolkit (also used by TheServerSide) is now finally released (RC1). Log4j 1.2 adds JMX support, Mapped Diagnostic Contexts, JDBC logging, graphical log viewer (chainsaw), buffered IO capability, and other changes to facilitate migration from the JDK 1.4 logging API to log4j.

Get Log4J 1.2 http://jakarta.apache.org/log4j/docs/download.html.

This is a good news...
too bad Sun didn't empaded log4j in the 1.4 distro, because java.util.logging just stink!

Yeah, java.util.logging is nothing compared to log4j. Though is it nice that Sun at last has come up with a logging API.

Apache has released a Jakarta sub-project called "Commons Logging" which stands as a facade over several different logging systems such as Log4J, JDK 1.4, LogKit...

Jakarta Commons Logging

Loggers are obtained from a LogFactory, and implement a common interface containing standard services such as trace(), debug(), info(), warn(), error() and fatal().

Which logging system is used is determined according to system variables / JDK 1.3 Jar Discovery Mechanism / properties files.

It is up to the user to configure the logging system in use, meaning some infrastructure code need to be written, but not that much.

The bad point is that the current version of this project (1.0) is not compatible with Log4J 1.2, but this will probably change in a near future !!

Laurent

How is it not compatible with log4j 1.2? commons logging is just a simple wrapper.

We are using Log4j 1.2 with the commons logging on a project with no issues.

Chuck

Thought the now deprecated Category API in Log4J was used by the Commons Logging wrapper to front Log4J.
Anyway, glad to hear Jakarta Commons Logging is fully compatible with Log4J 1.2 !

Laurent

If the wrapper does use Category, my understanding from reading the log4j 1.2 garb is that Category is deprecated but is still there for backwards compatability.

I think I also remember it saying that support will be removed at a later date.

When JDK1.02 came out I wrote my own logging libs. Used them for 6 years. Then javasoft does one in jdk1.4, it is OK, it does the trick. So I now use that.

And yet, a whole bunch of folks with log4j are going to keep pursuing their own because they know it to be 'better'. I bet they also bemoan different app servers for proprietary extensions.....

Jonathan

I don't think it's fair to bash log4j for being superfluous. It was there first after all. Perhaps Sun should be bashed for not using log4j.

BTW. What's wrong with competition?

Jonathan,

I don't see anything wrong with continuing the development of log4j. First, as another poster pointed out - it was here first! It is much more mature than Sun's logging facility. It also *much* more entrenched.

And what if it *is* better? Why would anybody want to use an inferior logging facility when a battle-tested, superior one already exists?

And one more thing - you may be interested in reading a critique by the author(s) of log4j on JSR47 (which became the java.util.logging). I would take to heart a critique from somebody who has worked with Java logging for years :-)

This is crying out for an application server friendly solution. There is a real hole in the market here.

The only possible doubt is that JDK 1.4 may address some of these issues and the effort wasted.

The following is not a criticsm of log4j, it is quite clearly designed for a non-application server environment, but is just some of my findings from looking at a logging framework that will allow for container based logging.

I want to leverage log4j in my EJB's, however I'm concerend about it doing its own threading, something that is disallowed in an EJB container. It is clear that AsyncAppender manages its own concurrency, but it is not clear if other parts of log4j do also.

JMSAppender only supports topics. It also looks up objects directly on the JNDI tree, it could be enhanced to allow a connection factory and topic to be supplied as these could then be retirved from the EJB environment context using managed resources etc. the JDBC appender allows you to override the getConnection method and so I assume this could be used to take advantage of connections obtained from JDBC DataSources. perhaps the JMSAppender coud also take advantage of these methods

You are not allowed to access java.io from within a container, which precludes using the most useful file based logging fom the container.

It seems that any EJB container based solution would need to have log4j running outside the container listening to a JMS destination that has log messages written to it.

I already know that to get the context of where the message was logged, I'm going to have to repeat a lot of what is already in the formatting classes. I need such things as the timestamp, thread id, Logger(was category), classname (in the event that I have not used fully qualified class names as my Logger names), the method name and line number etc. All the things that log4j gives me.

It would be cool if the Layout classes can be used for this without having to also use the Logger and Appender classes.

It would be nice to be able package all this up into a MapMessage (thinking on my feet here) and pass this as the JMS message payload.

The biggest problem, and correct if I'm wrong is that you cannot guarantee the message order in JMS which means the logs will be all over the place unless you do something to order them.

Presumably this is where chainsaw comes in or maybe placing them in a database - presumably chainsaw has the advantage of being used against a file, in which case you would have to be very careful with formatters because you can have a format per appender per category, making it impossible to parse a file with mixed formats unless you add a format id.

If you wanted to leverage the Logger heirarchies, appenders and layout functionality you would effectively log the messages again once you get them out of the JMS destination. You have the Logger available so you can get this, you would need to ensure that formatting that produces timestamps is tuened off otherwise this will confuse things big time, thread is's would need to be extracted from the JMS message etc

Am I barking mad, barking up the wrong tree or talking any sense whatsoever?

Mike (if that is indeed your real name),

Perhaps I am being naive here, but I don't see why you can't plug in your own appenders that work within the context of an app server. From what I can tell, the Appender, Layout and LoggingEvent interfaces/classes have no notion of IO or synchronization. Why can't you just have log4j statements in you enterprise code, and then a create a class(es) that implements Appender that "hook" into you app server? Surely this can be done, heh?

For example, say your Appender class acts as a proxy to whatever messaging API you are using (JMS, MDB, etc). This class (using its configured Layout, Filters, etc.) would how the message should look and whether it should be logger, and then pass this message along to the messaging API. The messaging system is transparent to the code that is doing to logging.

Basically, it appears that a lot of the appenders you mentioned that ship with log4j do a lot of queuing, IO, sync etc. for you. This is in lieu of having a container do this for you. If your app server provides these (and the specs forbid you from implementing these yourself), then why can't you write your own implementations that leverage these capabilities for you?

Am I on crack here, or is this a feasible solution? My JMS experience is minimal, so feel free to shoot holes in my theory. I'm just thinking that the Appender could be a POJO (plain ol' java object) that in turn talks to an enterprise component.

Well, I guess it's bad and against the spec, but I use log4j in my EJBs and I can say that it has not caused any harm within the last two years. Of course this might be different for another J2EE container, but in WebLogic it works just nicely...

Daniel

Hi,

log4j may have been first. And I agree that JavaSoft is silly to have gone their own way if they could have easily adopted yours.

But they didn't. So the choice is now between the standard logging libs which are good enough, or log4j which is also good enough. I choose the standard libs. Because they are standard - lets face it, logging aint that big a deal.

Surely standards are good. What log4j is now doing is splitting the core language, and I'm sure that when you started doing Java the log4j commiters would hate folks who split the language. Loads of folks produce cool non standard stuff. But as tech moves on they are left stranded. The choice is to fight the flow, maybe get them to adopt your apis (unlikely), compete and so muddy the waters or gracefully leave the game and move on.

eg. I did swing libs for earlier JDK but ditched them when the real swing stuff worked. I did a servlet container to the specs, until the real servlet container worked....

I'm being devils advocate a bit, because you can simply compete, as you are, which is fine as well.

Jonathan

This was my attitude too, but then I tried the new logging package. It couldn't yet handle the stuff I was already doing in log4j. Maybe the next version of it will be more flexible but when will that be? JDK 1.5? I think it was a mistake to bundle the logging package into the JDK this early in its life. Swing, JAXP, etc benefited from being able to release whenever they felt like as opposed to be constrained by the JDK releases.

log4j will be around for a while. It's embedded throughout my 35,000 line application. Until I upgrade to JDK 1.4, I can't replace log4j. Even when I do upgrade, there is no real benefit to me to switch over.

Hi Daniel,
I have a same kind or requirement. I have used log4j in WAS4.0 in my servlets and now i would like to extend the same logging in my EJBs too. When i tried to add the logging bit in my code, the EJB container cribbed a lot about it. Is there anyway i can have the EJB to write to a specific log file.

Thanks
Sriram

I am also successfully using log4j in websphere now, weblogic before, also with no problems, using configure and wait, async appenders, with the jdbc log and jms appenders, socket appenders, etc. If you look at some of the ibm redbooks on was, they also mention log4j directly.

Could you PLEASE give me details as to how you implemented LOG4J with WAS?

Hi,

I've taken a look at the new JDL Logging API; I've read the critique-article; but I have not read the JSR spec (could not find the text). Is that true that the spec defines how the API should be implemented, e.g. things concerning configuration? If not then Sun has a chance to improve the implementation in the next releases of the JDK.

Log4J is great but standard's weight is huge. I think Log4J will fade as the new API will be more and more accepted. Alas!

True ! Despite Category is a deprecated API, it is still there for compatibility reason (actually I think they've modified the class hierarchy so that Category extends Logger, but Logger is now the API to use).
So now we are ready to use Log4J 1.2, its remote console and JMX capabilities !

Reagrding JDK 1.4 API vs Log4J vs ..., I think the number of different logging systems is precisely the reason why the guys from Apache came out with a Common Logging System.

Laurent

For those of you still forced to used a version of the JDK prior to 1.4 I implemented a version of the logging API's.

You can use this to either interface onto your applications or write your own loggers. Then when you decided to move to JDK 1.4 it shouldn't be less of a problem.

Oh they're free, and they come with a nice little Swing Console for monitoring your logging - with a seperate panel for severe errors. I may migrate a copy of the Swing console to the 1.4 APIs.

The URL is ...

http://www.javelinsoft.com/jlogger

Hi Dear Log4j experts,

Could you pls help me in following 3 questions about LOG4J?
1. How to use DataSource to Log info into database?
2. When I log info into a database, can I use a stored procedure in database to log, not SQL statement?
3. How to use multi-thread in logging?


Thank you very much!
Simon