12 Replies Latest reply on Dec 10, 2007 4:39 PM by dmlloyd

    Updating the logging framework(JBAS-2412)

    starksm64

      I have a logging prototype for using the native jdk logging framework that uses handlers/formatters ported from the log4j codebase to provide something similar to the current log4j logging. Its checked into head common module under the org.jboss.logging.jdk package. The org.jboss.Main has been updated to install a custom jdk LogManager that bootstraps the configuration from the jdklogger.xml classpath resource to provide seamless integration with the jdk logger.

      Starting jboss with -ljdk triggers this behavior.

      Todos include:
      1. Add a Log4jService equivalent for the jdk logger
      2. Port additional log4j appenders. In general these cannot be in the common module as they carry additional dependencies, and the core logging in commons should be a minimal package around the consol and file appenders.

        • 1. Re: Updating the logging framework (JBAS-2412)
          starksm64
          • 2. Re: Updating the logging framework(JBAS-2412)
            genman


            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

              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


                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

                  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


                    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

                      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

                        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

                          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

                             

                            "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

                              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

                                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.