> On Nov 2, 2024, at 3:51 PM, Piotr P. Karwasz <pi...@mailing.copernik.eu>
> 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
> implementation, while Logback and JUL will be integrated in an internal
> package of the API (so we can remove them later).
>
> Once we smooth the API (naming, naming and again naming ;-) ), I can ping
> Ceki and see if he is willing to adopt it in Logback. Potentially there are a
> lot of places, where the API could replace logging implementation specific
> code ([1] and [2]). I pretty much doubt that those projects have both an
> implementation for Log4j Core and Logback.
I think you missed my point. I don’t think Log4j-core, Logback or whatever
should need to implement anything. The point of such an API is to provide a
standard API that implements whatever is necessary to perform the action. i.e.
in Log4j’s case setLEvel would call Configurator.setLevel.
Ralph
