-
1. Re: Updating the logging framework (JBAS-2412)
starksm64 Oct 31, 2005 10:36 AM (in response to starksm64)A jira issue for this task: http://jira.jboss.com/jira/browse/JBAS-2412
-
2. Re: Updating the logging framework(JBAS-2412)
genman Feb 17, 2006 12:22 PM (in response to starksm64)
Hi Scott.
The Log4j folk finally committed the deadlock-free appends into the 1.3 log4j tree. Unfortunately most of the changes are living in a separate subversion tree but the two can be merged together. You also have to patch how they re-use StringBuffer objects for generating output and their thread-unsafe date formatter, this is included in the bug.
http://issues.apache.org/bugzilla/show_bug.cgi?id=24159
It may in fact be easier to write what you want for the JDK appender rather than dealing with the Log4j team. Please let Log4j know what you think. -
3. Re: Updating the logging framework(JBAS-2412)
starksm64 Feb 17, 2006 7:50 PM (in response to starksm64)We already have a fixed log4j fork and a jdk logger with log4j appenders so the real question is why even bother upgrading the log4j core? Neither of these has been integrated into a jboss branch.
I'm tempted to just start using the jdk logging framework with the log4j appenders. If we went that route the only question would be what type of backward compatibility to provide. The Log4jService could be left for user apps, extended to support both log4j and an xmlized jdk logger config, etc. -
4. Re: Updating the logging framework(JBAS-2412)
genman Feb 17, 2006 9:18 PM (in response to starksm64)
Since I'm a user that's using log4j for my application, it doesn't necessarily help me very much if JBoss abandons support for log4j.
Obviously for your team, "it's not my problem" is an acceptable answer. It would be nice for somebody other than myself to remind them it is an issue, however. You don't owe me any favors, of course.
I could rewrite my code to use commons-logging or something else as well. Giving up is perhaps the safest option. -
5. Re: Updating the logging framework(JBAS-2412)
starksm64 Feb 17, 2006 10:22 PM (in response to starksm64)As I mentioned we would keep log4j as the default application logging framework. As to whether jboss uses a patched log4j core vs a jdk logging core with better appenders based on log4j, its a question of the path of least resistance. The latter seems simpler to me.
I'm not following who "them" is. -
6. Re: Updating the logging framework(JBAS-2412)
genman Feb 22, 2006 1:58 PM (in response to starksm64)
I was asking for support from JBoss to provide feedback to the Log4j team ("them") on incorporating the necessary fixes and changes JBoss wants for the 1.3 release. -
7. Re: Updating the logging framework(JBAS-2412)
rmaucher May 11, 2006 7:28 PM (in response to starksm64)In Tomcat, I have developed a LogManager which accepts a per classloader logging configuration (by having a logging.properties in the classloader). Otherwise, the default log manager of the JDK will use a global configuration (could be acceptable), and a global log namespace (will cause problems), so real usage of java.util.logging in a container needs a custom LogManager IMO.
http://svn.apache.org/viewcvs.cgi/tomcat/tc6.0.x/trunk/java/org/apache/juli/ -
8. Re: Updating the logging framework(JBAS-2412)
anil.saldhana Jun 21, 2006 1:03 PM (in response to starksm64)What is the final end-result of this discussion?
Third party project integration like MyFaces, SunXACML etc make use of the JDK logger. I know the feature request is still open. -
9. Re: Updating the logging framework(JBAS-2412)
starksm64 Jun 21, 2006 1:26 PM (in response to starksm64)It should be easier to switch the server between jdk logging/log4j implementations and have essentially the same configuration for appenders. Better support for this does exist in head. My inclination is to just switch to the jdk logging with the forked log4j appenders in jboss5 to eliminate another common area of conflict between user apps and the server.
-
10. Re: Updating the logging framework(JBAS-2412)
ssilvert Jun 21, 2006 1:43 PM (in response to starksm64)"anil.saldhana@jboss.com" wrote:
What is the final end-result of this discussion?
Third party project integration like MyFaces, SunXACML etc make use of the JDK logger. I know the feature request is still open.
Actually, MyFaces uses commons logging. The JSF CDDL (aka "The RI") uses the JDK logger.
Currently, the JSF CDDL integration in JBoss 5 just intercepts all JDK logging messages with a filter. Then it converts the message to Log4J and re-logs it. This was a simple solution for JSF because all logging is done through a small, well-defined set of Loggers. Attaching a filter to each logger was no problem and it guarded against forcing other applications to conform to any particular logging scheme.
This may not be a good approach in general because a project could use many loggers and you would need to attach a filter to every possible one.
Stan -
11. Re: Updating the logging framework(JBAS-2412)
genman Sep 28, 2006 12:18 AM (in response to starksm64)Just to follow up...
The Log4j 1.3 release (still in alpha) contains updated appenders to address concurrency concerns and fixes the deadlock issue.
http://svn.apache.org/repos/asf/logging/site/trunk/docs/BoardReports/board-report-2006-08.txt
It took about 3 years but there you go. -
12. Re: Updating the logging framework(JBAS-2412)
dmlloyd Dec 10, 2007 4:39 PM (in response to starksm64)So this discussion pretty much fizzled. Since I've been bitten by this issue yet again, I thought I'd opine a bit.
First point. The decision to use JDK logging or log4j on the backend should have ZERO impact on the user. A user should be able to use EITHER of these frameworks from their software, and the log messages should be categorized and filtered in the expected way. No, relying on the System.out/err capture facility is NOT adequate.
Second point. Due to the above point, switching to JDK logging should NOT mean that log4j support would cease to exist (and vice versa) - just that log4j log messages get mapped to JDK loggers. So application developers who use log4j should not have to stop using log4j.
Third point. JBAS 4.2.x still does not support JDK logging in ANY way out of the box. Booooo.
Fourth point. Framework developers (specifically, those at jboss.org) would be well advised to stick to using ONLY JDK logging. The reason for this is simple: using 3 or 4 frameworks that each require different logging frameworks means that the end user now also has a number of logging frameworks to track down and deliver with their product. Case in point: Remoting 3 as of now requires both slf4j AND log4j, and it doesn't even use either one of these (it uses JDK logging)! If framework developers use ONLY JDK logging, the end user will have a much easier time integrating the framework.