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 getInstance(). In reality you
would have to know what the object should be for the implementation you are
using.
These two methods are part of the "locking" mechanism and they could
certainly be refactored in a more meaningful way.
The object passed to `getInstance` can be any Java object. Its purpose
is only to prevent access to the API to all subsequent callers that do
not own the object. An example of usage:
private static final Object LOGGING_ADMIN_TOKEN = new Object();
private final LoggingConfigurationAdmin =
LoggingConfigurationAdmin.getInstance(LOGGING_ADMIN_TOKEN);
The `getLoggerContext` method is only used internally, so that
implementations can tell which "logger context" has been locked.
Internally there is a map "logger context -> security token" that is
used to prevent unauthorized access.À priori I assumed that in a
multi-user environment, each application can configure its own logging
subsystem.
3. The only thing of real value you are getting out of this are the “Level”
methods.
Yes, this is the main purpose of the API.
I would think this would have to live in its own repo. It should be able to
support Logback, Log4j-Core, and JuL simply by checking which is present. In
other words, the API and the implementation would all reside together in one
jar. I know you hate doing that but anything else is overkill iMO.
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.
Piotr
[1] https://github.com/search?q=LogManager.getContext%28false%29&type=code
[2]
https://github.com/search?q=LoggerFactory.getILoggerFactory%28%29&type=code
