You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Volkan Yazıcı <vo...@gmail.com> on 2020/03/04 08:23:47 UTC

shade+relocate policy & parsing JSON

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, JsonTemplateLayout uses Jackson both to parse the
template and to render JSON. The former still needs to be addressed,
i.e., I need a JSON parser. In order to qualify for "core", that needs
to be accomplished without any dependencies. I thought of using ANTLR
for parsing JSON, but that auto-generates Java sources depending on
antlr4-runtime. May I shade+relocate antlr4-runtime? Do you have any
suggestions on how to implement a dependency-free JSON parser?

Kind regards.

Re: shade+relocate policy & parsing JSON

Posted by Matt Sicker <bo...@gmail.com>.
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, Gary Gregory <ga...@gmail.com> wrote:
>
> 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 any cost. I just don't see the need for that.
>
> Gary
>
> On Wed, Mar 4, 2020, 11:03 Ralph Goers <ra...@dslextreme.com> wrote:
>
> >
> >
> > > On Mar 4, 2020, at 1:23 AM, Volkan Yazıcı <vo...@gmail.com>
> > 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 Jackson in JsonTemplateLayout: reading the JSON
> > > schema. That is, JsonTemplateLayout uses Jackson both to parse the
> > > template and to render JSON. The former still needs to be addressed,
> > > i.e., I need a JSON parser. In order to qualify for "core", that needs
> > > to be accomplished without any dependencies. I thought of using ANTLR
> > > for parsing JSON, but that auto-generates Java sources depending on
> > > antlr4-runtime. May I shade+relocate antlr4-runtime? Do you have any
> > > suggestions on how to implement a dependency-free JSON parser?
> >
> > Not really. I am not sure avoiding the use of a JSON parser library just
> > to include the JsonTemplateLayout in core is worth the effort. People who
> > want to use JSON aren’t going to mind bringing in a JSON library. And if it
> > means adding a JSON parser to core that we have to maintain, unless it is
> > just a couple of classes I don’t know that I would want to do that.
> >
> > Ralph
> >
> >
> >



-- 
Matt Sicker <bo...@gmail.com>

Re: shade+relocate policy & parsing JSON

Posted by Gary Gregory <ga...@gmail.com>.
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 any cost. I just don't see the need for that.

Gary

On Wed, Mar 4, 2020, 11:03 Ralph Goers <ra...@dslextreme.com> wrote:

>
>
> > On Mar 4, 2020, at 1:23 AM, Volkan Yazıcı <vo...@gmail.com>
> 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 Jackson in JsonTemplateLayout: reading the JSON
> > schema. That is, JsonTemplateLayout uses Jackson both to parse the
> > template and to render JSON. The former still needs to be addressed,
> > i.e., I need a JSON parser. In order to qualify for "core", that needs
> > to be accomplished without any dependencies. I thought of using ANTLR
> > for parsing JSON, but that auto-generates Java sources depending on
> > antlr4-runtime. May I shade+relocate antlr4-runtime? Do you have any
> > suggestions on how to implement a dependency-free JSON parser?
>
> Not really. I am not sure avoiding the use of a JSON parser library just
> to include the JsonTemplateLayout in core is worth the effort. People who
> want to use JSON aren’t going to mind bringing in a JSON library. And if it
> means adding a JSON parser to core that we have to maintain, unless it is
> just a couple of classes I don’t know that I would want to do that.
>
> Ralph
>
>
>

Re: shade+relocate policy & parsing JSON

Posted by Ralph Goers <ra...@dslextreme.com>.

> On Mar 4, 2020, at 1:23 AM, Volkan Yazıcı <vo...@gmail.com> 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 Jackson in JsonTemplateLayout: reading the JSON
> schema. That is, JsonTemplateLayout uses Jackson both to parse the
> template and to render JSON. The former still needs to be addressed,
> i.e., I need a JSON parser. In order to qualify for "core", that needs
> to be accomplished without any dependencies. I thought of using ANTLR
> for parsing JSON, but that auto-generates Java sources depending on
> antlr4-runtime. May I shade+relocate antlr4-runtime? Do you have any
> suggestions on how to implement a dependency-free JSON parser?

Not really. I am not sure avoiding the use of a JSON parser library just to include the JsonTemplateLayout in core is worth the effort. People who want to use JSON aren’t going to mind bringing in a JSON library. And if it means adding a JSON parser to core that we have to maintain, unless it is just a couple of classes I don’t know that I would want to do that.

Ralph