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?

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...

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.

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.

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.

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.

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?

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.