Those all sound like good ideas. Based on my lack of success last year, I
may wish to submit multiple CFPs. I’ll follow up as I’ve submitted them.
On Wed, Mar 4, 2020 at 19:16 Ralph Goers wrote:
> If I was doing a talk it would probably be on “Logging in the Cloud” with
> a focus on our Spring,
If I was doing a talk it would probably be on “Logging in the Cloud” with a
focus on our Spring, Docker, and Kubernetes support.
Another valuable talk could be one about the advantages of using the Log4j 2
API instead of SLF4J. I would definitely note how commit activity on SLF4J and
Logback h
I almost forgot that I noted an idea last year to do a State of Logging
Services type of presentation considering there were a few others like that
accepted then. Such a talk could touch on all our components.
On Tue, Mar 3, 2020 at 08:17 Matt Sicker wrote:
> Considering we’re on track to log4j
JSON itself is a fairly simple grammar to parse, though doing so in
Java requires a third library party or a tediously written parser.
Can you implement schema support in a pluggable way to allow it to be
done in its own module? Or are schemas required for this layout?
On Wed, 4 Mar 2020 at 10:10
My typical development follow 1 of 2 paths.
1. I am doing a patch or new feature targeted at the 2.x release train. I do my
initial development on the release-2.x branch. Once it is fully tested I
cherry-pick it (when possible) to the master branch. If I can’t cherry-pick it
I manually copy th
Shading Antlr or another parser, generated or in a library, is out of
bounds IMO. Writing our own JSON parser is not a good idea either, it's not
something a logging library should be in the business of maintaining, IMO
again. It just feels to me like you just want jam your new module in core
at an
> On Mar 4, 2020, at 1:23 AM, Volkan Yazıcı wrote:
>
> Hello,
>
> I have managed to produce JSON in JsonTemplateLayout without using
> Jackson. I have successfully implemented all existing features with
> the exception of pretty printing, which I will leave out. There is a
> 2nd use case for
Hello,
While developing it is really difficult to keep up with the master
branch, it continuously gets broken. master and release-2.x diverge a
lot as well, hence I am sitting on the fence for whether I should base
my changes on master or release-2.x. This is my current state:
$ git remote -v
ori
Hello,
I have managed to produce JSON in JsonTemplateLayout without using
Jackson. I have successfully implemented all existing features with
the exception of pretty printing, which I will leave out. There is a
2nd use case for Jackson in JsonTemplateLayout: reading the JSON
schema. That is, JsonT
