Mailing-List: contact log4j-dev-help@logging.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Log4J Developers List" <log4j-dev@logging.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
From: Jacob Dall <jd@eurisco.dk>
To: Log4J Developers List <log4j-dev@logging.apache.org>
Subject: RE: API and setLevel / getEffectiveLevel
Thread-Topic: API and setLevel / getEffectiveLevel
Thread-Index: Ac4m6VZVE9qOB3mYQGKLQV/soojq7gAI6bIAAJNA8kD///UzgP//uLhw
Date: Mon, 25 Mar 2013 16:56:30 +0000
Message-ID: <F99158DF8887AB4583E218E21FF57E8E087D97@ADM-EXMBX10A.adm.c.sdu.dk>
References: <F99158DF8887AB4583E218E21FF57E8E0845ED@ADM-EXMBX10A.adm.c.sdu.dk>
 <4C4EA24A-71D8-407A-A4B2-36009CB79E1B@dslextreme.com>
 <F99158DF8887AB4583E218E21FF57E8E086819@ADM-EXMBX10A.adm.c.sdu.dk>
 <92A9AEDC-6FB0-4B4E-B64E-7A030393E8D1@dslextreme.com>
In-Reply-To: <92A9AEDC-6FB0-4B4E-B64E-7A030393E8D1@dslextreme.com>
Accept-Language: da-DK, en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam_score: -2.9
X-Spam_score_int: -28
X-Spam_bar: --
X-Virus-Checked: Checked by ClamAV on apache.org

Well, basically because I haven't thought of doing it that way - probably b=
ecause it was not an issue with the currently used logger core to do it the=
 way we did ;)

I'll have to look further into it, but I like the idea - thanks for sharing=
 it.

Jacob


-----Original Message-----
From: Ralph Goers [mailto:ralph.goers@dslextreme.com]=20
Sent: 25. marts 2013 14:31
To: Log4J Developers List
Subject: Re: API and setLevel / getEffectiveLevel

So why wouldn't you create a custom Configuration that merges the configura=
tion file and database settings?  That avoids all the problems I mention be=
low.

Ralph

On Mar 25, 2013, at 6:23 AM, Jacob Dall wrote:

> I understand your concern and what you are trying to achieve.
>=20
> My only concern about setLevel / getEffectiveLevel not being available in=
 the API is that someone should 'suddenly' remove these methods from the im=
plementation, leaving programmers using these with a BIG issue.
> What are the risk of methods disappearing from the implementation, once p=
ut into action?
>=20
> FYI, in our particular case we use the configuration file to define logge=
r "types" but not logger levels. Simply because we have like a gazillion (g=
reatly exaggerated, of course, but you get the idea) of each type of logger=
, that depends on how the system is used. Log levels are instead stored in =
a database.
>=20
> Thanks
> Jacob
>=20
> -----Original Message-----
> From: Ralph Goers [mailto:ralph.goers@dslextreme.com]=20
> Sent: 22. marts 2013 16:53
> To: Log4J Developers List
> Subject: Re: API and setLevel / getEffectiveLevel
>=20
>=20
>=20
> On Mar 22, 2013, at 3:38 AM, Jacob Dall wrote:
>=20
>> Dear "Log4j 2" developers
>>=20
>> In the "Migration from Log4j 1.x" manual, "Converting to the Log4j 2 API=
" clause, it is written:
>>=20
>> "4. Calls to logger.setLevel or similar methods are not supported in the=
 API. Applications should remove these. Equivalent functionality is provide=
d in the Log4j 2 implementation classes but may leave the application susce=
ptible to changes in Log4j 2 internals."
>>=20
>> If an application needs to set the levels programmatically, it probably =
does so for a good reason. One can't "just remove these", if there is nothi=
ng to put instead.=20
>>=20
>> Why is that functionality not available from the API?=20
>>=20
>> Would it cost many tears and a lot of sweat to add it?
>=20
>=20
> There are several reasons. =20
>=20
> 1. The API is for users of Log4j who want to log events and who want guar=
antees that the API they are coding to will remain stable.  Once you start =
programmatically modifying the logging configuration you are now outside th=
e bounds of that safe API and into the implementation.  This was one of the=
 fundamental problems with Log4j 1 and is one of the reasons Ceki created S=
LF4J and Logback. =20
> 2. Log4j has thread safety issues and performance issues.  Many of these =
are because the API exposes things that cause these problems.=20
> 3. If you programmatically modify a log level and then the external confi=
guration is changed your programmatic change will be lost.  This is not a s=
how stopper but anyone doing this needs to be aware the change isn't perman=
ent.
> 4. Applications that want to programmatically modify the configuration ne=
ed to do it in a manner compatible with the implementation. Log4j 2 allows =
several ways for the configuration to be modified. Just not through the pub=
lic API. =20
>=20
> Ralph
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>=20


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org