Towards 3.0 (was Re: Filtering out excessive log payloads)

[Ralph Goers <ra...@dslextreme.com>]

Moved to a separate topic since none of this has much to do with the questions that were asked.


> On Mar 3, 2020, at 6:52 AM, Gary Gregory <ga...@gmail.com> wrote:
> 
> Hi All (I'm back from vacation today):
> 
> For 3.0, my thoughts are that the 'core' should only include infrastructure
> used to implement actual appenders and layouts (and filters and so on.)


I have always stated that I am fine with anything being in core so long as it doesn’t bring in required dependencies. With 3.0 I would like core to have as few optional dependencies as possible as well. 

> 
> My experience with the products that use Log4j 1 and 2 at work is:
> - Use the Console appender by default.
> - No consistent usage of at least one kind of File appender (where the
> layout is always a pattern.)
> - One or more JDBC Appender

To be honest, I’ve never understood the use case for this.  I don’t believe it belongs in core.

> - One or more JMS Appender

This one also seems a bit dated. RabbitMQ, Kafka, Pulsar seem like better choices in todays world. I don’t believe any of these belong in core.

> - A few _Custom_ appenders

File, RollingFile, RandomRollingFile, Console, Socket, Syslog are the bread and butter of logging and should absolutely be in the default deliverable.  


> 
> The JDBC and JMS Appenders clearly (to me) should live in their own module.
> Since there is no 'always use this kind of file appender', file appenders
> should live in one or more of their own modules.
> 
> Maybe Matt's new configuration code is flexible enough to be in a separate
> module, I do not know yet.
> 
> Certainly each kind of layout should live in it's own module which is
> already almost in place for 3,0.
> 

Disagree again. The 80/20 rule is at play here. Today, I would guess that PatternLayout and JSONLayout are the two most popular and should be in core. I am actually using the GelfLayout simply because I found it works better at getting logs into ELK than our JsonLayout - which means our JsonLayout needs work as the GelfLayout should be unnecessary.  Of course SyslogLayout and RFC5424Layout are useful if you are logging to syslog and neither has any dependencies so they belong in core.

There is such a thing as making things too fine grained. It isn’t very user friendly to have to include 10 jars just to do some simple logging.  At the same time, it is no fun to have to manually exclude dependencies that shouldn’t be required.

Ralph

Re: Towards 3.0 (was Re: Filtering out excessive log payloads)

[Matt Sicker <bo...@gmail.com>]

I'd like to keep log4j-core dependency-free (other than log4j-api of
course), so any plugins that only require java.base seem fine to
include in core. We'll likely need some optional dependencies for
asynchronous logging and such, but simplifying the dependencies here
would be great.

On Tue, 3 Mar 2020 at 10:37, Ralph Goers <ra...@dslextreme.com> wrote:
>
> Moved to a separate topic since none of this has much to do with the questions that were asked.
>
>
> > On Mar 3, 2020, at 6:52 AM, Gary Gregory <ga...@gmail.com> wrote:
> >
> > Hi All (I'm back from vacation today):
> >
> > For 3.0, my thoughts are that the 'core' should only include infrastructure
> > used to implement actual appenders and layouts (and filters and so on.)
>
>
> I have always stated that I am fine with anything being in core so long as it doesn’t bring in required dependencies. With 3.0 I would like core to have as few optional dependencies as possible as well.
>
> >
> > My experience with the products that use Log4j 1 and 2 at work is:
> > - Use the Console appender by default.
> > - No consistent usage of at least one kind of File appender (where the
> > layout is always a pattern.)
> > - One or more JDBC Appender
>
> To be honest, I’ve never understood the use case for this.  I don’t believe it belongs in core.
>
> > - One or more JMS Appender
>
> This one also seems a bit dated. RabbitMQ, Kafka, Pulsar seem like better choices in todays world. I don’t believe any of these belong in core.
>
> > - A few _Custom_ appenders
>
> File, RollingFile, RandomRollingFile, Console, Socket, Syslog are the bread and butter of logging and should absolutely be in the default deliverable.
>
>
> >
> > The JDBC and JMS Appenders clearly (to me) should live in their own module.
> > Since there is no 'always use this kind of file appender', file appenders
> > should live in one or more of their own modules.
> >
> > Maybe Matt's new configuration code is flexible enough to be in a separate
> > module, I do not know yet.
> >
> > Certainly each kind of layout should live in it's own module which is
> > already almost in place for 3,0.
> >
>
> Disagree again. The 80/20 rule is at play here. Today, I would guess that PatternLayout and JSONLayout are the two most popular and should be in core. I am actually using the GelfLayout simply because I found it works better at getting logs into ELK than our JsonLayout - which means our JsonLayout needs work as the GelfLayout should be unnecessary.  Of course SyslogLayout and RFC5424Layout are useful if you are logging to syslog and neither has any dependencies so they belong in core.
>
> There is such a thing as making things too fine grained. It isn’t very user friendly to have to include 10 jars just to do some simple logging.  At the same time, it is no fun to have to manually exclude dependencies that shouldn’t be required.
>
> Ralph
>
>


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

Re: Towards 3.0 (was Re: Filtering out excessive log payloads)

[Gary Gregory <ga...@gmail.com>]

A different POV I have lately is playing around with a Raspberry Pi, which
is a touch more resource constrained than a Windows or Linux box. I am also
working on an Arduino project but I can't run Java there.

Gary

On Tue, Mar 3, 2020, 11:37 Ralph Goers <ra...@dslextreme.com> wrote:

> Moved to a separate topic since none of this has much to do with the
> questions that were asked.
>
>
> > On Mar 3, 2020, at 6:52 AM, Gary Gregory <ga...@gmail.com> wrote:
> >
> > Hi All (I'm back from vacation today):
> >
> > For 3.0, my thoughts are that the 'core' should only include
> infrastructure
> > used to implement actual appenders and layouts (and filters and so on.)
>
>
> I have always stated that I am fine with anything being in core so long as
> it doesn’t bring in required dependencies. With 3.0 I would like core to
> have as few optional dependencies as possible as well.
>
> >
> > My experience with the products that use Log4j 1 and 2 at work is:
> > - Use the Console appender by default.
> > - No consistent usage of at least one kind of File appender (where the
> > layout is always a pattern.)
> > - One or more JDBC Appender
>
> To be honest, I’ve never understood the use case for this.  I don’t
> believe it belongs in core.
>
> > - One or more JMS Appender
>
> This one also seems a bit dated. RabbitMQ, Kafka, Pulsar seem like better
> choices in todays world. I don’t believe any of these belong in core.
>
> > - A few _Custom_ appenders
>
> File, RollingFile, RandomRollingFile, Console, Socket, Syslog are the
> bread and butter of logging and should absolutely be in the default
> deliverable.
>
>
> >
> > The JDBC and JMS Appenders clearly (to me) should live in their own
> module.
> > Since there is no 'always use this kind of file appender', file appenders
> > should live in one or more of their own modules.
> >
> > Maybe Matt's new configuration code is flexible enough to be in a
> separate
> > module, I do not know yet.
> >
> > Certainly each kind of layout should live in it's own module which is
> > already almost in place for 3,0.
> >
>
> Disagree again. The 80/20 rule is at play here. Today, I would guess that
> PatternLayout and JSONLayout are the two most popular and should be in
> core. I am actually using the GelfLayout simply because I found it works
> better at getting logs into ELK than our JsonLayout - which means our
> JsonLayout needs work as the GelfLayout should be unnecessary.  Of course
> SyslogLayout and RFC5424Layout are useful if you are logging to syslog and
> neither has any dependencies so they belong in core.
>
> There is such a thing as making things too fine grained. It isn’t very
> user friendly to have to include 10 jars just to do some simple logging.
> At the same time, it is no fun to have to manually exclude dependencies
> that shouldn’t be required.
>
> Ralph
>
>
>