You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Richard Sitze <rs...@us.ibm.com> on 2005/01/04 19:42:59 UTC
Re: commons-logging auto-detection
Paul Libbrecht <pa...@activemath.org> 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: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: commons-logging auto-detection
Posted by Dennis Lundberg <de...@mdh.se>.
robert burrell donkin wrote:
>
> On 7 Jan 2005, at 08:43, Paul Libbrecht wrote:
>
>>
>> Le 6 janv. 05, à 22:46, robert burrell donkin a écrit :
>>
>>> given the extra layer proposed, the discovery/configuration mechanism
>>> that should be employed for the JVM would be set by a system property
>>
>>
>> Careful to offer one alternative to system properties... (maybe like a
>> LoggingProperties class which does not load any other class): System
>> properties are often not readable and not writable in some
>> environments and commons-logging has been quite much sandbox-friendly
>> thus far...
>
>
> i haven't been able to think of any general mechanism for JVM level
> configuration that would work well in strongly sandboxed environments.
> it's critical that the base API classes are very portable and small. i'd
> be glad to hear of any suitable alternatives...
>
> at the moment, if the system property cannot be read, it will be
> ignored. this behaviour would be retained. it would then default to
> trying to load LogFactory (for backwards compatibility) and use that for
> discovery (thus defaulting to the current behaviour). if LogFactory
> cannot be loaded, it would fall back on a very simple logging
> implementation (which would probably print ERROR and FATAL to System.err).
>
> IIRC in these kinds of environments the JCL currently has many issues.
> i've proposed that the general solution for heavily secured environments
> (such as untrusted applets) would be to dope the application (using byte
> code engineering) so that all references to JCL are rewired to a logger
> appropriate to that environment (one which would, for example, just
> print ERROR and FATAL level messages to System.err). i believe that this
> would allow JCL to be used successfully in a much wider variety of
> environments.
We use JCL in both untrusted and signed applets. There used to be issues
with the sandbox before, but with the release of 1.0.4 these issues are
gone.
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: commons-logging auto-detection
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 7 Jan 2005, at 08:43, Paul Libbrecht wrote:
>
> Le 6 janv. 05, à 22:46, robert burrell donkin a écrit :
>
>> given the extra layer proposed, the discovery/configuration mechanism
>> that should be employed for the JVM would be set by a system property
>
> Careful to offer one alternative to system properties... (maybe like a
> LoggingProperties class which does not load any other class): System
> properties are often not readable and not writable in some
> environments and commons-logging has been quite much sandbox-friendly
> thus far...
i haven't been able to think of any general mechanism for JVM level
configuration that would work well in strongly sandboxed environments.
it's critical that the base API classes are very portable and small.
i'd be glad to hear of any suitable alternatives...
at the moment, if the system property cannot be read, it will be
ignored. this behaviour would be retained. it would then default to
trying to load LogFactory (for backwards compatibility) and use that
for discovery (thus defaulting to the current behaviour). if LogFactory
cannot be loaded, it would fall back on a very simple logging
implementation (which would probably print ERROR and FATAL to
System.err).
IIRC in these kinds of environments the JCL currently has many issues.
i've proposed that the general solution for heavily secured
environments (such as untrusted applets) would be to dope the
application (using byte code engineering) so that all references to JCL
are rewired to a logger appropriate to that environment (one which
would, for example, just print ERROR and FATAL level messages to
System.err). i believe that this would allow JCL to be used
successfully in a much wider variety of environments.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: commons-logging auto-detection
Posted by Paul Libbrecht <pa...@activemath.org>.
Le 6 janv. 05, à 22:46, robert burrell donkin a écrit :
> given the extra layer proposed, the discovery/configuration mechanism
> that should be employed for the JVM would be set by a system property
Careful to offer one alternative to system properties... (maybe like a
LoggingProperties class which does not load any other class): System
properties are often not readable and not writable in some environments
and commons-logging has been quite much sandbox-friendly thus far...
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: commons-logging auto-detection
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 4 Jan 2005, at 19:15, Paul Libbrecht wrote:
> Le 4 janv. 05, à 19:42, Richard Sitze a écrit :
>> 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:
>
> Well, if I was in control of the application, that would be true but I
> am not.
> (more or less).
> I still insist on something like a method static
> LogFactory.getLogFactoryOfThread() which would use a previous call to
> LogFactory.setLogFactoryOfThread(LogFactory).
i'd see that this kind of thing is exactly what an additional
configuration layer could enable. i'd be very, very reluctant to see
this added into JCL as it is at the present since it would added
complexity which would only be useful for a limited set of
environments. in others it may be positively harmful (for example,
server environments where threads are pooled).
given the extra layer proposed, the discovery/configuration mechanism
that should be employed for the JVM would be set by a system property.
each pluggable implementation would be capable of supporting whatever
extra configuration it needed. so, ThreadLogFactory (for example) might
discovery the right implementation to use based on the value of a
thread local variable and could support setters (as described above).
when a brick was used by an application running in a suitable
environment, the application would just need to ensure that the
appropriate system property was set and then the LogFactory discovery
would use the thread local mechanism.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: commons-logging auto-detection
Posted by Paul Libbrecht <pa...@activemath.org>.
Le 4 janv. 05, à 19:42, Richard Sitze a écrit :
> 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:
Well, if I was in control of the application, that would be true but I
am not.
(more or less).
I still insist on something like a method static
LogFactory.getLogFactoryOfThread() which would use a previous call to
LogFactory.setLogFactoryOfThread(LogFactory).
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org