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.
-
Log4J 1.2 Released (22 messages)
- Posted by: Floyd Marinescu
- Posted on: May 10 2002 16:02 EDT
Threaded Messages (22)
- Log4J 1.2 Released by Herve Tchepannou on May 10 2002 16:17 EDT
- Log4J 1.2 Released by Pee Wee on May 11 2002 01:18 EDT
-
Log4J 1.2 Released by Laurent Rieu on May 11 2002 08:01 EDT
- Log4J 1.2 Released by Web Master on May 11 2002 08:28 EDT
-
Log4J 1.2 Released by Chuck Cavaness on May 12 2002 02:59 EDT
-
Log4J 1.2 Released by Laurent Rieu on May 13 2002 03:26 EDT
-
Log4J 1.2 Released by Web Master on May 13 2002 05:40 EDT
-
Log4J 1.2 Released by Jonathan Gibbons on May 13 2002 06:50 EDT
- Log4J 1.2 Released by Wouter Zelle on May 13 2002 09:02 EDT
-
Log4J 1.2 Released by Ryan Breidenbach on May 13 2002 09:18 EDT
-
Log4J 1.2 Released by Web Master on May 13 2002 01:20 EDT
-
Log4J 1.2 Released by Ryan Breidenbach on May 13 2002 01:45 EDT
-
Log4J 1.2 Released by Daniel Hoppe on May 14 2002 03:00 EDT
-
Log4J 1.2 Released by Jonathan Gibbons on May 14 2002 08:46 EDT
- Log4J 1.2 Released by Neil Weber on May 14 2002 11:48 EDT
- Log4J 1.2 Released by Sriram Sankar on July 07 2002 12:15 EDT
-
Log4J 1.2 Released by Jonathan Gibbons on May 14 2002 08:46 EDT
-
Log4J 1.2 Released by Daniel Hoppe on May 14 2002 03:00 EDT
-
Log4J 1.2 Released by Jin Chun on May 14 2002 11:00 EDT
- Log4J 1.2 Released by Abhilash Nair on August 09 2002 02:43 EDT
-
Log4J 1.2 Released by Ryan Breidenbach on May 13 2002 01:45 EDT
- Log4J 1.2 Released by Al Le on May 14 2002 11:00 EDT
-
Log4J 1.2 Released by Web Master on May 13 2002 01:20 EDT
- Log4J 1.2 Released by Laurent Rieu on May 13 2002 07:33 EDT
-
Log4J 1.2 Released by Jonathan Gibbons on May 13 2002 06:50 EDT
-
Log4J 1.2 Released by Web Master on May 13 2002 05:40 EDT
-
Log4J 1.2 Released by Laurent Rieu on May 13 2002 03:26 EDT
-
Log4J 1.2 Released by Laurent Rieu on May 11 2002 08:01 EDT
- Log4J 1.2 Released by Pee Wee on May 11 2002 01:18 EDT
- Log4J 1.2 Released by Robin Sharp on May 16 2002 10:00 EDT
- Log4J 1.2 Released by Jia Shifeng on October 23 2002 03:16 EDT
-
Log4J 1.2 Released[ Go to top ]
- Posted by: Herve Tchepannou
- Posted on: May 10 2002 16:17 EDT
- in response to Floyd Marinescu
This is a good news...
too bad Sun didn't empaded log4j in the 1.4 distro, because java.util.logging just stink! -
Log4J 1.2 Released[ Go to top ]
- Posted by: Pee Wee
- Posted on: May 11 2002 01:18 EDT
- in response to Herve Tchepannou
Yeah, java.util.logging is nothing compared to log4j. Though is it nice that Sun at last has come up with a logging API. -
Log4J 1.2 Released[ Go to top ]
- Posted by: Laurent Rieu
- Posted on: May 11 2002 08:01 EDT
- in response to Pee Wee
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 -
Log4J 1.2 Released[ Go to top ]
- Posted by: Web Master
- Posted on: May 11 2002 20:28 EDT
- in response to Laurent Rieu
How is it not compatible with log4j 1.2? commons logging is just a simple wrapper. -
Log4J 1.2 Released[ Go to top ]
- Posted by: Chuck Cavaness
- Posted on: May 12 2002 14:59 EDT
- in response to Laurent Rieu
We are using Log4j 1.2 with the commons logging on a project with no issues.
Chuck -
Log4J 1.2 Released[ Go to top ]
- Posted by: Laurent Rieu
- Posted on: May 13 2002 03:26 EDT
- in response to Chuck Cavaness
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 -
Log4J 1.2 Released[ Go to top ]
- Posted by: Web Master
- Posted on: May 13 2002 05:40 EDT
- in response to Laurent Rieu
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. -
Log4J 1.2 Released[ Go to top ]
- Posted by: Jonathan Gibbons
- Posted on: May 13 2002 06:50 EDT
- in response to Web Master
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
-
Log4J 1.2 Released[ Go to top ]
- Posted by: Wouter Zelle
- Posted on: May 13 2002 09:02 EDT
- in response to Jonathan Gibbons
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? -
Log4J 1.2 Released[ Go to top ]
- Posted by: Ryan Breidenbach
- Posted on: May 13 2002 09:18 EDT
- in response to Jonathan Gibbons
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 :-) -
Log4J 1.2 Released[ Go to top ]
- Posted by: Web Master
- Posted on: May 13 2002 13:20 EDT
- in response to Ryan Breidenbach
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? -
Log4J 1.2 Released[ Go to top ]
- Posted by: Ryan Breidenbach
- Posted on: May 13 2002 13:45 EDT
- in response to Web Master
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. -
Log4J 1.2 Released[ Go to top ]
- Posted by: Daniel Hoppe
- Posted on: May 14 2002 03:00 EDT
- in response to Ryan Breidenbach
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 -
Log4J 1.2 Released[ Go to top ]
- Posted by: Jonathan Gibbons
- Posted on: May 14 2002 08:46 EDT
- in response to Daniel Hoppe
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
-
Log4J 1.2 Released[ Go to top ]
- Posted by: Neil Weber
- Posted on: May 14 2002 11:48 EDT
- in response to Jonathan Gibbons
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.
-
Log4J 1.2 Released[ Go to top ]
- Posted by: Sriram Sankar
- Posted on: July 07 2002 12:15 EDT
- in response to Daniel Hoppe
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 -
Log4J 1.2 Released[ Go to top ]
- Posted by: Jin Chun
- Posted on: May 14 2002 11:00 EDT
- in response to Web Master
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. -
Log4J 1.2 Released[ Go to top ]
- Posted by: Abhilash Nair
- Posted on: August 09 2002 14:43 EDT
- in response to Jin Chun
Could you PLEASE give me details as to how you implemented LOG4J with WAS? -
Log4J 1.2 Released[ Go to top ]
- Posted by: Al Le
- Posted on: May 14 2002 11:00 EDT
- in response to Ryan Breidenbach
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! -
Log4J 1.2 Released[ Go to top ]
- Posted by: Laurent Rieu
- Posted on: May 13 2002 07:33 EDT
- in response to Web Master
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 -
Log4J 1.2 Released[ Go to top ]
- Posted by: Robin Sharp
- Posted on: May 16 2002 10:00 EDT
- in response to Floyd Marinescu
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
-
Log4J 1.2 Released[ Go to top ]
- Posted by: Jia Shifeng
- Posted on: October 23 2002 03:16 EDT
- in response to Floyd Marinescu
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