commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Nichols <nx10m...@yahoo.co.uk>
Subject Re: [logging] How to setLevel() for commons logging? (urgent :)
Date Wed, 02 Apr 2003 20:23:27 GMT
At 09:01 02/04/2003 -0800, Craig R. McClanahan wrote:


>On Wed, 2 Apr 2003, Thomas Nichols wrote:
>
> > Date: Wed, 02 Apr 2003 16:13:25 +0100
> > From: Thomas Nichols <nx10mail@yahoo.co.uk>
> > Reply-To: Jakarta Commons Users List <commons-user@jakarta.apache.org>
> > To: commons-user@jakarta.apache.org
> > Subject: [logging] How to setLevel() for commons logging? (urgent :)
> >
> > Hi,
> > I'm using Commons Logging to get Logger independence. By default I'm using
> > Log4J, and I want to ship my kit configured by default to WARN level. In
> > Log4J I'd use logger.setLevel(Level.WARN), but the commons.logging.Log
> > interface has no setLevel() or similar method, and I can't see how to get
> > to the underlying Log4J Category field. How can I ship with logging set to
> > WARN (or OFF)?
> >
>
>Configuration of the underlying logging system implementation is *not* the
>responsibility of commons-logging.

Understood.

>That is up to your application.  For
>Log4J, that means doing something like:
>
>* Shipping a "log4j.properties" file in your app that Log4J
>   will automatically recognize and use to configure itself.

Yeah, l may end up doing this - I was trying to avoid any config files to 
get "default" behaviour - in this case, showing only WARN level and up.

>* Explicitly calling one of the Configurator methods to set
>   things up the way you want.

Thanks - I had looked at these, but seemed to need the encapsulated Logger 
-- but Logger.getRootLogger() is fortunately static, I can setLevel on 
that. Works for me.

Has a commons.logging.Log.setLevel() been ruled out for architectural 
reasons? This would have kept my code generic.

Thanks,
Thomas.





> > I can do this ok with SimpleLog...
> >
>
>That's because SimpleLog is a (simple) logging system implementation, so
>it needed to provide a configuration mechanism.
>
> > Looks as though this project ends the Log4J / JDK1.4 logging debate for me
> > - thanks very much.
> >
>
>That's the idea :-).
>
> > Regards,
> > Thomas.
> >
>
>Craig
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message