2 Replies Latest reply on Mar 16, 2006 10:04 AM by Francisco Reverbel

    Log4jLoggerFactory Configuration Via log4j.xml?

    Jimmy Wilson Apprentice

      The integration of JacORB's use of the Avalon logging framework with Log4j is accomplished through the use of the org.jboss.util.Log4jLoggerFactory class. In addition to wrapping Log4j-based loggers with Avalon loggers for use by JacORB, it provides for the setting of logging levels via the jacorb.properties file with *.log.verbosity properties, but I think use of these properties has some unintended consequences:

      First, if I were to set the jacorb logger's level to DEBUG given the following log4j.xml snippet:

      <logger name="jacorb">
       <level value="DEBUG"/>
      </logger>


      I would think that all jacorb-based loggers would be set to DEBUG. However, due to the specificity of the *.log.vebosity properties, children of the jacorb.* loggers have already been set to WARN, and consequently, the above log4j.xml snippet above has no effect.

      Second, if I were to set the jacorb.orb.giop logger's level to DEBUG given the following log4j.xml snippet:

      <logger name="jacorb.orb.giop">
       <level value="DEBUG"/>
      </logger>


      I would think that GIOP-related information would be logged at the DEBUG level. However, because of the jacorb.orb.giop.log.verbosity=2 property setting in jacorb.properties, the logging level is overridden to be WARN (the ORB-related stuff loads after the Log4j-related stuff). Furthermore, when I touch the log4j.xml file after JBoss AS has been running for some time: the logging level of the jacorb.orb.giop logger gets set to DEBUG.

      Given that the purpose of Log4jLoggerFactory is to integrate JacORB's logging capability with Log4j, and that having logging configuration in two places can be confusing, might it be simpler if the Log4jLoggerFactory class was changed to remove the extra *.log.verbosity property functionality so that the log4j.xml file controlled its logging levels as expected?

      I'll be creating a JIRA issue shortly that captures this unexpected behavior along with diff's of patched code.