Is there any support for something like an Avalon logging wrapper to an underlying log4j engine? I was thinking about this for the James project... log4j has really robust file logging (rollover, formatting, filtering, etc...) and so if I have the log messages in James get delivered to log4j, then we can get a solid logging backend pretty quickly.
Serge:
Adding a Log4J implementation simply requires that a pluggable implementation wrapper be written (i.e. and implementation of the o.a.a.repository.provider.Factory interface that returns an implementation of o.a.a.logging.provider.LoggingManager). In principal this should be simpler that the LogKit implementation because Log4J already includes an XML configuration model. One item that will need to be added is a multicast target because the component meta-data model only allows a single target to be assigned to a particular logging channel (whereas the Log4J logger allows association of multiple targets to a single logger). A multicast target simply redirects a log event to a set of named targets (or appenders if we use Log4J terminology) thereby preserving the single target name approach.
In the meantime the logkit based implementation addresses the minimum requirements put forward by the James project concerning Phoenix to Merlin migration.
* complete separation of the logging implementation from merlin
* logging implementations are loaded using the avalon-repository
facilities via an artifact spec (e.g.
avalon-logging/avalon-logkit-impl?version=1.0-SNAPSHOT)
* the default implementation is LogKit based solution
which provides:
- a core set of logging targets
* rotating file
* stream (e.g. console style
* multicast
* plugin target that loads custom targets using the
avalon-repository package - current target plugins
in cvs include
* a datagram target
* a socket target
- standard formatter that uses the avalon util exception
reporting utilities
* standard mode
* cosole mode
- customizable log formattingOne of the things I have not looked at yet concerning Log4J is the separation of targets (appenders) with respect to dependencies (and in particular the level of package separation in jar files). This is also a potential issue with LogKit. As things stand with LogKit there are references in the LogKit impl to things like JMS classes (as an example). This means that if your want to use the JMS target, the JMS classes *must* be in the same or higher classloader as LogKit itself which in turn means that the strengths of the plugable target scenario is significantly reduced without some repackaging at the LogKit distribution level. In the case of LogKit this is resolvable but in the case of Log4J my guess is that we would need to work with the Log4J team to figure out the best approach.
Cheers, Stephen.
--
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/merlin/distributions/latest | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
