Re: New API for log level manipulation
On Sat, Nov 2, 2024 at 11:15 PM Ralph Goers wrote: > > > > 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 > 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
Re: New API for log level manipulation
Hi Gary, On 3.11.2024 13:23, Gary Gregory wrote: On Sat, Nov 2, 2024 at 11:15 PM Ralph Goers wrote: 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. I merged everything into a single artifact and applied your other suggestions[1]. If we more or less agree on how this should look like, I can create an `apache/logging-admin` repo and work out the details in PRs. Piotr [1] https://github.com/ppkarwasz/logging-admin
Re: Bridges in 2.x and 3.x
Gary, On 25.10.2024 08:19, Ralph Goers wrote: With the changes that have been made the bridges only have a dependency on Logj4 API - which is only in the 2.x branch. Should these artifacts only be on the 2.x branch as well? These bridges don’t change nearly as often as core or even api do. IMO releasing them with every release doesn’t make a lot of sense. To be honest, I would have suggested that the API and everything that is only dependent on the API (except for core) be in a separate repo with its own release schedule. This would match pretty much what SLF4J does. Are you suggesting that the bridges be included in both 2.x and main? Are you suggesting that the bridges MUST be versioned the same as 2.x despite them almost never having any changes? I’m simply trying to understand what your rationale is here. Can you address Ralph's remarks? Where do you propose the bridges should stay: * on both the `2.x` and `main` branches, * on only the `2.x` branch, * in a separate repo with a separate release schedule. Piotr
