On Sat, Nov 2, 2024 at 11:15 PM Ralph Goers <ralph.go...@dslextreme.com> wrote:
> > > > 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. > I like Ralph's POV. We define the API, and since we have our core implementations and bridges for other logging systems, we put the new code in there. Gary > > Ralph
