Hi,
This may be related but I was fighting recently with embedding Jelly within jEdit which, of course, has its own class-loading mechanism because of plugins.
I simply did not manage to have jelly:log messages directed to my console but it may be not so important.
I realized that one thing that would have strongly advantaged me is to be able to "pre-load" the current logging factory (or even a "context logger", of which all child-loggers that would be created would appear) set as a thread-local static instance.
This way, as long as we understand classloading times (which is really not that hard), it is possible for plugins that use other things that use logging to actually influence this logging.
I would choose this to have priority to others, at least if a certain system property is set.
paul
Le 2 janv. 05, � 22:50, robert burrell donkin a �crit :
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
