> On Nov 2, 2024, at 3:51 PM, Piotr P. Karwasz
> wrote:
>
> This would be the same setting as in Commons Logging, so I guess I would be
> OK with that, if we keep an extension mechanism in the API. We could probably
> split the implementation in two parts: Log4j Core can receive his
> impl
Hi Ralph,
On 2.11.2024 22:48, Ralph Goers wrote:
1. getLoggerContext returns a meaningless object. The object returned only has
value if you know what it is and if you do then you might as well be tied to
whatever the implementation is.
2. You are passing in an arbitrary parameter to getInstan
Hi Gary,
On 2.11.2024 23:14, Gary D. Gregory wrote:
In general, talking about API signatures without (pseudo)-Javadoc is not great,
there is too much wrong for miscommunication or plain old guesing.
FWIW, the JavaDoc is there in my repo[1] together with a short
README[2]. I only removed it to
Hi all,
On 31.10.2024 16:11, Piotr P. Karwasz wrote:
Currently we have `o.a.l.l.c.config.Configurator` that allows level
manipulation, but this is a Log4j Core specific class, which only
works with Log4j Core. We could publish a small API (e.g. called
LogAdmin) that allows to:
* list the con
Hi Piotr,
In general, talking about API signatures without (pseudo)-Javadoc is not great,
there is too much wrong for miscommunication or plain old guesing.
> Set getSupportedLevels();
It is not helpful to return a set IMO . This should be a list in a documented
order from one min or max
To be honest, I have never been a fan of this kind of interface because:
1. getLoggerContext returns a meaningless object. The object returned only has
value if you know what it is and if you do then you might as well be tied to
whatever the implementation is.
2. You are passing in an arbitrary
