Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: how should log levels work? [Was Re: [Logging] default log level]
Content-Transfer-Encoding: quoted-printable
Date: Wed, 9 Jan 2002 12:26:36 -0800
Message-ID: <458473676F1AC74A84EAB2F22004DA6DD87F@mail.nextance.com>
Thread-Topic: how should log levels work? [Was Re: [Logging] default log
 level]
Thread-Index: AcGZSz4aFZGhBd4sTAyDNOL3EZ5f4wAAE/rQ
From: "Scott Sanders" <ssanders@nextance.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>

> -----Original Message-----
> From: Paulo Gaspar [mailto:paulo.gaspar@krankikom.de]=20
> Sent: Wednesday, January 09, 2002 12:41 PM
> To: Jakarta Commons Developers List
> Subject: RE: how should log levels work? [Was Re: [Logging]=20
> default log level]
>=20
>=20
> > I can see your viewpoint, but I think that it is sometimes=20
> necessary.=20
> > What if my component logs to 25 categories but I give you=20
> an easy way=20
> > to cascade it by calling the main setLevel().
>=20
> Such complex component MUST have some configuration mechanism for the=20
> logger.

Possibly, but it you plug that component into your framework which uses
LogKit, wouldn't you just want LogKit to take over and handle it.  In
that case you do NOT need setLevel.  I was refering to the case when you
do NOT have Log4J or LogKit or JDK1.4.  But as Craig once said, this is
a VERY slippery slope.

>=20
> The logger may have too. With Log4J there is a XML=20
> configuration file and with Avalon's LogKit there is a=20
> similar mechanism that is still hiding in another part of the API.

Yes.

>=20
>=20
> But I also wrote:
> > >    Notice that I believe in being able to set the level in some
> > >    common configuration mechanism, just not on the interface.
>=20
> Which means that there should be a (maybe optional) logging=20
> mechanism that helps you configure that kind of thing. But=20
> after that, you just use a Logger with no setLevel().
>=20
>=20
> Anyway, if by the People demand the setLevel() must exist, then I=20
> still think it should always work, whatever was the original=20
> level. Otherwise it even looks broken!

I am not demanding that it exist.  From a purist, 'I want the smallest
wrapper possible perspective', I would not support it.  But I do think
it has a use.

Scott

>=20
>=20
> Have fun,
> Paulo Gaspar
>=20
>=20
> > -----Original Message-----
> > From: Scott Sanders [mailto:ssanders@nextance.com]
> > Sent: Wednesday, January 09, 2002 8:23 PM
> >=20
> >=20
> > I can see your viewpoint, but I think that it is sometimes=20
> necessary.=20
> > What if my component logs to 25 categories but I give you=20
> an easy way=20
> > to cascade it by calling the main setLevel().
> >=20
> > Scott
> >=20
> > > -----Original Message-----
> > > From: Paulo Gaspar [mailto:paulo.gaspar@krankikom.de]
> > > Sent: Wednesday, January 09, 2002 11:39 AM
> > >=20
> > >=20
> > > I personally think you should avoid changing the log level
> > > after the configuration step.
> > >=20
> > > However, I also agree that if you call setLevel() is because
> > > you really want to change the level and are supposed to know=20
> > > what you are doing.
> > >=20
> > > The 2 alternatives that make more sense to me:
> > >  - A setLevel() that always changes the level;
> > >=20
> > >  - No setLevel() at all.
> > >    The (Avalon) wrappers I use work this way and I never miss that
> > >    thing. I am not sure if it is such a common need that it should
> > >    have a place in this common interface.
> > >=20
> > >    Notice that I believe in being able to set the level in some
> > >    common configuration mechanism, just not on the interface.
> > >=20
> > >=20
> > > Have fun,
> > > Paulo Gaspar
> > >=20
> > >=20
> > > > -----Original Message-----
> > > > From: Scott Sanders [mailto:ssanders@nextance.com]
> > > > Sent: Wednesday, January 09, 2002 7:28 PM
> > > >
> > > >
> > > > I think that all calls should push through to the
> > > underlying system,
> > > > and that if possible the set/getLevel methods should operate on=20
> > > > the
> > > > underlying implementation.
> > > >
> > > > Scott
> > > > ...
>=20
>=20
> --
> To unsubscribe, e-mail:  =20
> <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> For=20
> additional commands,=20
> e-mail: <mailto:commons-dev-help@jakarta.apache.org>
>=20
>=20

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>