ppkarwasz commented on issue #3240: URL: https://github.com/apache/logging-log4j2/issues/3240#issuecomment-2503683841
> Hey @ppkarwasz , thanks for the quick reply. I tested and using a `StatusLogger` worked, but the question remains: why we suddenly needed to use it? As mentioned in the description, using a regular logger worked fine before `2.24.2`. The problem you are encountering is due to the `DEFAULT_MESSAGE_FACTORY` field being uninitialized (so `null`). Up to Log4j 2.22.x, that field was in the Log4j API (its classes are initialized before `LoggerContext`) and was initialized using reflection and a configuration property specific to Log4j 2 ([the `log4j2.messageFactory` property](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.messageFactory)). That solution is no longer viable: - It is not extensible. Since the release of `2.24.0`, Log4j Core 3 is based on the same version of Log4j API as Log4j Core 2 (see [documentation](https://logging.apache.org/log4j/3.x/manual/api.html)), but uses dependency injection for many services (including `MessageFactory`). - It causes problems for GraalVM, since we would need to register with GraalVM all possible `MessageFactory` implementations in advance. - It causes other initialization problems: since 2.23.x `StatusLogger` uses `AbstractLogger`, but is initialized **before** `PropertiesUtil`, which is used to determine the right `MessageFactory`. These are the main reasons we moved the initialization of the default message factory at a later stage. **Note**: we can easily fix the initialization problem, by moving `DEFAULT_MESSAGE_FACTORY` at the top of the `LoggerContext` class, but I have mixed feeling about this approach: - I don't think it is needed. Using any `o.a.l.l.Logger` other than `o.a.l.l.status.StatusLogger` in a Log4j Core Plugin class is IMHO bad practice. Using an `org.slf4j.Logger` in such a class is even less recommended. - The real problem is elsewhere: the `DefaultConfiguration` and `NullConfiguration` implementations used by `LoggerContext` before and after the real configuration is loaded, should probably be pretty minimal and should not require lookups and other advanced services, since they are basically **immutable**. We should probably go in this direction, but this might require breaking changes, which are not allowed in 2.x. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
