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 <[email protected]> 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 <[email protected]> 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 > > >
