This document relates to JIRA issue JBAS-6097 which entails creating a POJO-based service for Logging for JBossAS 6.0.

Update: The implementation of these requirements has been merged into JBossAS and will appear in 6.0.

Requirements:

1. The logging service will allow applications using any logging API to function as expected (reference: forum discussion).  Included in this set of APIs are:
1. JDK logging (java.util.logging)
2. Clients using the Log4J API directly
3. Clients using the old Apache commons-logging framework
4. Clients using the SLF4J API
5. Clients using the JBoss common logging API
2. The logging service will allow deployments to have separate handing for stdout and stderr (reference: JBAS-2412) (TODO: this could be abstracted out of logging, and merged with the ability to have per-deployment stdin)
   
3. The logging service should allow the user to specify log appenders and handlers from any of the following frameworks (reference: JBAS-2412):
1. JDK logging Handlers
2. Log4j Appenders
4. Deployments should still be able to use the old log4j.xml/jboss-log4j.xml configuration style (reference: forum discussion).
1. Appenders defined in this configuration format should be assumed to be Log4j Appenders. (Ed: there's probably no harm in just detecting the appender type programmatically and supporting all types)
2. Log4j Filters should continue to be supported.
3. Levels configured in log4j.xml should be supported for log4j level types.
4. (..todo - other log4j config types..)
5. A new, updated (JBossMC metadata-based) configuration format should be introduced which offers configuration support for the full range of features defined above.
6. The management view (XMBean?) should retain largely the same (or similar) operations as the old logging service (some of the docs reference log4j-specific things; those will want updating).
1. The service should produce a notification when a logging deployment is complete (similar to a reconfigure notification under Log4jService).
7. A bootstrap configuration mechanism should be available that allows the primordial appenders to be set up, including:
1. The console appender
2. The boot log file appender
8. When the "real" configuration service starts, the primordial appenders should be replaced with the new configured appenders. The bootstrap configuration mechanism is no longer needed at this point and can be unloaded.
9. On shutdown, the appenders need to be retained until the moment of container shutdown or else some shutdown logs might be lost. the logging configuration will be retained until the logging deployments are all stopped, at which time the bootstrap logging configurations will be restored and remain in place until the container shuts down.

Non-Requirements:

1. The ability to support multiple backend logging frameworks (unless someone can demonstrate a good reason for this).

Implementation Notes:

1. The logging backend will use JDK logging by way of the enhanced JBoss LogManager.
2. Logging deployments will be translated into Microcontainer bean deployments.
1. As a result, no more than one logging deployment (log4j or otherwise) will be able to define the same logger (i.e. the same category name in the same logging context); such a deployment will trigger an error.  (TODO: what about the root logger?)
   
2. More than one log4j deployment may use the same name for appenders as their names will be private to a logger deployment.  (TODO: this appears to be how DOMConfigurator works today; do we need a way for one deployment to reference appenders from another deployment?  JBMC would then automatically create a dependency between the deployments... that could be good or bad)
3. The JBoss Logging API should use the slf4j backend the backend provided with JBoss LogManager going forward, not the JDK logging backend, since it is more feature-complete.
4. The log4j JAR (in whole or in part) will need to be a part of the logging service deployer (as opposed to using a minimal facade such as what is provided with slf4j) in order to support log4j appenders and filters and other structure. (TODO: what about NDC/MDC?  These classes will have to forward to our versions.) (TODO: is log4j deployment compatibility really a requirement?  Might be easier to just provide a logging repository implementation which bridges back to the core logmanager (opposite of the original logbridge) and let the regular log4j configurators do their thing).
   
5. Bootstrap changes:
1. Remove log4j-boot.jar - no longer needed.
2. JBoss LogManager remains; the JDK LogManager has to be on the classpath at the time that logging is initialized.
3. Remove jboss-logging-log4j.jar and jboss-logging-jdk.jar (the only backend which is needed at boot is included in the JBoss LogManager)
4. jboss-logging-spi.jar remains to support the components which use JBoss Logging at boot (which is pretty much all of them).
5. Remove jboss-logbridge.jar - no longer needed
6. Add slf4j-api.jar - the 1.1.0 version of JBoss LogManager implements this API directly.