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 commons-logging.properties 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 commons-logging.properties 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
