commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: commons-logging auto-detection
Date Sun, 02 Jan 2005 21:50:48 GMT

On 28 Dec 2004, at 00:40, Matt Sgarlata wrote:

> I think often JCL will be used as you describe, but not always.
> For example, let's say I am developing a component that monitors 
> database activity and monitors usage statistics (this is a 
> hypothetical example).  The main purpose of this component is to log 
> messages to be processed later by a human.  I use JCL and put a 
> in my org.dbmonitor package that says "use 
> Log4J and display INFO and higher messages".
> This component may be deployed in many different environments.  Here 
> are two examples:
> 1) Standalone on a server.  In this case, the default settings 
> specified at the component level should be used.
> 2) As a component of another application.  In this case, the overall 
> application specifies logging properties that overwrite those in the 
> component.  To do this, the application specifies a 
> in the default package, which overwrites 
> the properties specified at the component level.  In this example, the 
> application chooses it only wants WARN and higher messages and that it 
> wants the messages rendered with JDK 1.4 logging.
> My point is that one overall configuration of logging for the entire 
> JVM may be too restrictive.  I think we could benefit from multiple 
> JCL configurations, each targeted at different parts of a system.

i think that the idea we're going forward with is that there needs only 
to be one discovery configuration for the whole of the JVM (not one 
logging implementation). when a request for a log is received, the 
pluggable discovery mechanism chosen by the configuration determines 
how the bridging implementation is assigned. at the present, the 
discovery mechanism is not configurable and is implemented in 
LogFactory. hopefully later, it would be possible to choose to use the 
current mechanism or use a system property to replace it with another 
completely different one.

FWIW i think that the package level discovery mechanism would be 
powerful in some use cases and would support such a discovery mechanism 
but only as pluggable implementation, not as part of the default 
discovery mechanism (the classloader issues concern me greatly).

- robert

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message