Yeah, I think you’re right, Ralph. Thanks for reasoning this over with me.
Returning quickly is still a good idea.
—
Matt Sicker
> On Dec 29, 2022, at 01:16, Ralph Goers wrote:
>
> The reason a DefaultConfiguration is created and NOT the identified
> configuration is that a) we would have to
The reason a DefaultConfiguration is created and NOT the identified
configuration is that a) we would have to block while the configuration is
created and b) creating a Configuration isn’t necessarily very fast depending
on what is in it (some of which we cannot control). We do want logging to b
It’s NullConfiguration that’s the overly-expensive null guard for preventing
operations from blowing things up during shutdown. There’s a small period of
time between the stopping of Log4j and the stopping of the JVM that other code
could still be trying to send new log messages, so they need to
And with this detail about the possibility for a Logger to be returned while
LoggerContext::start is being executed is indeed a reason for why
DefaultConfiguration _normally_ exists. I’m looking at two additional scenarios:
1. What if you provide a configuration location String or URI to the
Lo
Using LifeCycle more would be neat, though its semantics aren’t well defined.
In the Injector API, any no-arg method annotated with @Inject is considered
equivalent to a @PostConstruct-style method which is similar to
`LifeCycle::initialize`. The start() and stop() methods are more
domain-speci
Alright, let me clarify then:
Based on how things initialize in Log4j (at least in master, though probably
similarly in 2.x), the creation of a LoggerContext is effectively an atomic
operation, though it may be constructed more than once before returning a
common singleton instance (per ClassLo
Hi Ralph
On Wed, 28 Dec 2022 at 18:38, Ralph Goers wrote:
> > On Dec 28, 2022, at 7:01 AM, Piotr P. Karwasz
> > wrote:
> > I think we should rely more on our `LifeCycle` abstraction:
> > `Configuration` starts in the "initializing" state and does not have
> > any subcomponents (especially those
> On Dec 28, 2022, at 10:37 AM, Ralph Goers wrote:
>
>
>
> Ralph
>
>> On Dec 28, 2022, at 7:01 AM, Piotr P. Karwasz
>> wrote:
>>
>> Hi Matt,
>>
>> On Sun, 18 Dec 2022 at 20:30, Matt Sicker wrote:
>>> During this bootstrapping, if the configuration location is available (such
>>> as for
Ralph
> On Dec 28, 2022, at 7:01 AM, Piotr P. Karwasz wrote:
>
> Hi Matt,
>
> On Sun, 18 Dec 2022 at 20:30, Matt Sicker wrote:
>> During this bootstrapping, if the configuration location is available (such
>> as for a unit test), should LoggerContext set up the configuration provided?
>>
Hi Matt,
On Sun, 18 Dec 2022 at 20:30, Matt Sicker wrote:
> During this bootstrapping, if the configuration location is available (such
> as for a unit test), should LoggerContext set up the configuration provided?
> Or is there some sort of cyclic dependency here preventing us from loading
>
Applications can be multi-threaded. I believe we load the DefaultConfiguration
so other threads aren’t blocked by Log4j initialization. The statement that “no
logging can possibly occur until after at least said construction” isn’t true.
Ralph
> On Dec 27, 2022, at 12:12 PM, Matt Sicker wrote:
In this particular scenario, a file URI has been provided to the LoggerContext
constructor. Given the fact that a Logger instance itself is not constructed
until _after_ the LoggerContext has been constructed, no logging can possibly
occur until at least after said construction. In our current i
I am not really sure what the question here is. When you pass in a
configuration location you are going to end up with a LoggerContext that
references a Configuration derived from the information at that location. Yes,
it may create a DefaultConfiguration along the way but that is primarily
bec
13 matches
Mail list logo
