Paul Libbrecht <[EMAIL PROTECTED]> wrote on 01/04/2005 03:26:00 AM:
> 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 think that what you are asking for is a way to bind a LogFactory
instance to a particular ClassLoader, perhaps immediately following the
construction of the ClassLoader instance:
setFactory(ClassLoader, LogFactory);
Thoughts:
a. Under the auspices of the 'one config' policy, such an API would throw
an exception if an attempt were made to bind a LogFactory instance to a
ClassLoader which has a different LogFactory instance already bound to it.
b. Though this is a simple method to implement [it's cacheFactory made
public], keep it simple: we've talked about looking for a pluggable
discovery mech, with a minimalistic default discovery. The default
shouldn't exhibit this behavior, perhaps commons-discovery (JCD) can take
on this new idea.
Under this scheme, you would establish the presence of JCD in your JVM,
JCL LogFactory.getFactory [static method] would locate JCD and use it
instead of it's default internal mechanism. Your application code would
create a new ClassLoader, and use JCD.bind(ClassLoader, Object) to do the
binding.
>
> 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]
>
*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
