Inline
> // trimmed discussion about using annotations for documentation
>
> I was checking and it's not possible to have annotations on the enum
> values. We should still have an annotation for the Events enum types
> so that we can both:
> 1. Add context for that event group (eg: broker events,
> managed-ledger events, bk events, etc)
> 2. We can use the annotation processor to retrieve all enums tagged
> with that annotation
Yes, I've played around with this a bit before. I couldn't get it to
work. I set retention to runtime but it ended up missing. Will try
again.
> // trimmed discussion about TLS
>
> If this becomes complex or error-prone, I think we should consider
> that we're really most interested in bridging events from Pulsar to BK
> client. For example it would be very helpful to correlate events on a
> particular ledger back to the topic. We could also do that already
> without changing the APIs by including the ledger "properties" into
> the BK client log events, since we're already including the topic name
> there.
We can always modify methods to pass a context down. Regarding BK +
Pulsar bridging, I don't think we need to do much, as from Pulsar PoV
we want the callsite and the callback, which are code that live in the
Pulsar codebase. Eventually I would like to add this type of
instrumentation to BK also, but I consider Pulsar to be more pressing.
> // trimmed discussion about changing order and suppliers
>
> We can still put the event type at the very end:
>
> ```
> e.atInfo()
> .attr("result", lookupResult)
> .log(Events.LOOKUP);
> ```
This ends up with a similar problem to putting event at the "atInfo".
Normally, the pattern I described would be happy-case or error-case.
So if it was LOOKUP_ERROR, you'd need to change to error level at end.
Also it loses at lot of the benefit of the previous. Logging is not
going to be disabled at INFO, WARN or ERROR usually. It will be at
individual loggers at those levels (I plan to take logger from the
event itself).
-Ivan
