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 ne
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 impleme
> 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 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 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 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
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,
I would expect the LCD to allow
LogManager.setLevel("com.gary.app", "debug")
Having a Level version is OK as well.
Gary
On Thu, Oct 31, 2024, 1:25 PM Piotr P. Karwasz
wrote:
> Hi Gary,
>
> On 31.10.2024 17:12, Gary Gregory wrote:
> >
> >> set the configured level of a single logger
Hi Gary,
On 31.10.2024 17:12, Gary Gregory wrote:
set the configured level of a single logger
Some people (like me) will want to enable debug all in one go for example,
even for loggers that have not been instantiated yet.
I think we should distinguish whether this is set the level for a hie
Good idea!
One way I like to think about this is what is the API I need to build a
tree view UI that shows the logger hierarchy where I can toggle levels for
one logger or one logger tree (including the root).
>set the configured level of a single logger
Some people (like me) will want to enable
Hi all,
In last few days I have encountered the problem of retrieving and
setting the configured level of a logger twice (in Nashorn[1] and Apache
Kafka[2]). What do you think about introducing a public API to do this
sort of things in an implementation independent way?
Currently we have `o.
12 matches
Mail list logo
