Hi Volkan,
On Thu, 11 Apr 2024 at 21:26, Volkan Yazıcı wrote:
> *Slightly longer answer:* Log4j has never had a holistic observability view
> to its internals. We need something new (if not, from scratch), and
> preferably, applicable to not only async. logging, but all components
> wherever this
Hi All,
Our current Javadoc says:
/**
* Returns the content type output by this layout. The base class returns
"text/plain".
*
* @return the content type.
*/
String getContentType();
I'd like to clarify if returning null should be legal/allowed for
implementation in
We’ve got a new proposal from Piotr on this front now which sort of emulates
his suggestion for 3.x but applied to 2.x (since that doesn’t have the DI
system). I like the approach there as it provides enough of a hook for users to
customize whatever metrics library they wish to enhance some comp
We’ve got nullability annotations now, so we should be defining them. For use
cases like this, I’d examine how existing things work and then document the
nullability as such. For new code, I prefer things to be non-null except for
cases where it makes sense to use null rather than, say, passing
Matt,
That sounds appealing, but do you have to have this hook registered by the time
the disruptor is set up? That's my fundamental concern with a lot of these
interception strategies - if your library/framework is called (which ours is),
instead of being the entry point (as many others often
Hi Adam,
On Fri, 12 Apr 2024 at 21:42, Thomas, Adam wrote:
> That sounds appealing, but do you have to have this hook registered by the
> time the disruptor is set up? That's my fundamental concern with a lot of
> these interception strategies - if your library/framework is called (which
> our
This setup should work for us. While we don’t control logging initialization,
we will reliably be present on the classpath at initialization time, and
ServiceLoader should have no problems finding our implementation.
> You probably want to implement a "push" counter for the discarded messages,
