rocketraman commented on issue #71:
URL:
https://github.com/apache/logging-log4j-kotlin/issues/71#issuecomment-2004683273
> I understand your example but I am not sure how it works in practice. I
have to presume that the Connection class can operate on multiple Connection
instances. A Logger is a singleton - there will only be one instance no matter
how many Connection instances you create (to do otherwise would create an
insane number of Logger instances in the system). We generally recommend it be
declared as static as to do otherwise means a call is made to locate the Logger
instance every time a new instance of the class is created. What this means is
that you can't really have a per-resource context attached to a Logger. From
inside Log4j we would have no idea which instance of the object was used and
would not be able to locate the context.
@rgoers I'm talking about a *builder* which is not static. So imagine if you
will a static logger in the usual way. Then on top of that, you create an
object-level LogBuilder which contains your object-level context, which all
subsequent logging sites use as a starting point. For example:
```
class R {
private static final Logger baseLogger = LogManger.getLogger(R.class);
private final id = ...
private final logger = baseLogger.withContext(id)
fun doSomethingOnResource() {
logger.atInfo().log("foo");
}
}
```
> However, you could create an instance of the ScopedContext I proposed and
attach it to each instance of your Connection and then invoke the logic for
every method inside of a run method. It should be possible to use AOP to use an
annotation to cause that to happen automatically.
Yes, this is what I was proposing in my OP with `withContextMap`.
This is an ok solution but its verbose, and I personally dislike using AOP.
In my experience, AOP is almost always obviated by good architecture and APIs.
Kotlin's [trailing lambda
syntax](https://kotlinlang.org/docs/lambdas.html#passing-trailing-lambdas) and
delegation support makes AOP even more redundant. You may disagree but I don't
think log4j2 should require users to bring AOP into a project in order to have
a clean API surface.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
