Il Gio 13 Gen 2022, 09:48 Andor Molnar <an...@apache.org> ha scritto:

> Providing sample configs for logging backends which we don’t actively
> maintain. I don’t this is gonna work. Maybe log4j.properties is already
> broken too in some parts, because we don’t have test coverage / active user
> base for that. Sounds to me a waste of effort and error-prone practice.
>
> Using a more powerful backend for tests that we ship with our product
> neither makes sense to me. What would be the cons for the maintainers than
> using a single solution end-to-end?
>

At this point I believe that the best choices are:
- log4j2: the most used in the ZK ecosystem
- logback: very used, simpler
- JUL: always available

My preference goes to LogBack for the zookeeper tarball (and so the docker
images)

In my experience there is no need to super advanced configurations, like
log4j2
But a framework that is too simple won't work for production (like simple
slf4j).



Enrico



> Andor
>
>
>
> > On 2022. Jan 12., at 22:47, Christopher <ctubb...@apache.org> wrote:
> >
> > On Wed, Jan 12, 2022 at 10:48 AM Andor Molnar <an...@apache.org> wrote:
> >>
> >> slf4j-simple
> >> ~~~~~~~~~~~~
> >>
> >> Based on the documenation:
> >> "Simple implementation of Logger that sends all enabled log messages,
> for all defined loggers, to the console (System.err).”
> >> https://www.slf4j.org/api/org/slf4j/impl/SimpleLogger.html
> >>
> >> I see the following problems with this approach and don’t know how to
> deal with them:
> >>
> >> 1) We won’t be able to ship log config examples for
> Trace/Audit/File/RollingFile appenders as we did for log4j, because the
> simple backend doesn’t support any of them.
> >
> > Example Java system properties can be provided for slf4j-simple.
> > Examples for other runtimes can also be provided. The ability to
> > provide examples wouldn't change. To use example configs for other
> > runtime implementations, they just might need to be accompanied by
> > instructions on swapping out the runtime implementation on the class
> > path. Personally, I think the best place for such example configs and
> > instructions is as a "how-to" reference on the website, but it could
> > exist anywhere you provide documentation.
> >
> >>
> >> 2) Refactoring the tests is problematic, because we cannot capture log
> messages in an OutputStream. However this could be circumvented by
> capturing log messages on System.err probably. Need to dig more.
> >
> > Agreed that is problematic. I would avoid trying to capture
> > System.err. Although relatively simple to do in Java, it can break
> > things in surprising ways sometimes. For tests, I'd still recommend
> > using some non-simple implementation for the test class path,
> > regardless of what gets put in the distribution. Logback is as good as
> > any for the tests, and you've already done the work for that.
> >
> >>
> >> 3) Lack of MDC support is a problem with this backend too. We would
> have to use BasicMDCAdapter (hell knows how) which I guess requires changes
> in the main codebase.
> >>
> >> My 2 cents still goes for logback.
> >>
> >> Andor
> >>
> >>
> >>
> >>
> >>> On 2022. Jan 12., at 16:06, Andor Molnar <an...@apache.org> wrote:
> >>>
> >>> Ouch…
> >>> JUL doesn’t have MDC support.
> >>>
> >>>
> >>>
> >>>> On 2022. Jan 12., at 12:48, Andor Molnar <an...@apache.org> wrote:
> >>>>
> >>>> Thanks Chris and Christopher for resolving the licensing issue.
> >>>>
> >>>> Christopher, sorry for “fiasco” it might have not been accurate to
> describe what happened to log4j2 recently. Respect to Apache for responding
> quickly and I understand the reason that Ted mentioned why logback
> responded more reluctantly, although the problem in logback is far less
> severe. I also agree that less CVEs doesn’t mean more secure software. At
> the same time I believe less code leads to less CVEs. Maybe not always, but
> in most cases.
> >>>>
> >>>> All in all, I still tend to logback being better choice for ZooKeeper
> than log4j2. Mentioning the dependency hell-ish situation at the end of
> your e-mail sounds like a con.
> >>>>
> >>>> Let’s take a quick look at the other alternatives.
> >>>>
> >>>> Pat just opened my eyes recently that JUL (java.util.logging) could
> actually be a logging _backend_ of SLF4j instead of facade replacement. The
> biggest pro could be that it’s already built in JDK, no need to add further
> dependencies. I’m preparing a side-by-side patch for JUL migration just to
> see the differences.
> >>>>
> >>>> slf4j-simple could still be a viable option. I haven’t heard enough
> feedback from the community to say something for sure. (I will only prepare
> another PR for that, if I see strong desire from folks here.)
> >>>>
> >>>> Andor
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> On 2022. Jan 12., at 1:15, Chris Nauroth <cnaur...@apache.org>
> wrote:
> >>>>>
> >>>>> The licensing question is resolved. We can state our choice of EPL,
> and
> >>>>> include only the text of EPL.
> >>>>>
> >>>>> Chris Nauroth
> >>>>>
> >>>>>
> >>>>> On Mon, Jan 10, 2022 at 1:05 PM Ted Dunning <ted.dunn...@gmail.com>
> wrote:
> >>>>>
> >>>>>>
> >>>>>> I would add one more point. Logback has roughly benevolent dictator
> >>>>>> governance, Log4j is Apache. During the recent kerfuffle, Apache
> responded
> >>>>>> sooner because it only took one of n people to start responding.
> Logback's
> >>>>>> response for quite some time was "that's an Apache problem" even
> though
> >>>>>> they had very similar vulnerability through JNDI. The root cause of
> the
> >>>>>> vulnerability (in my opinion) was feature-itis but the BDFL model
> caused
> >>>>>> logback to lose considerable time before responding effectively.
> >>>>>>
> >>>>>> My own slightly-more-than-joking preference is to find the logging
> >>>>>> framework with the fewest features and options. I seriously doubt
> if the
> >>>>>> speed differences can be measured in a realistic situation and the
> risk of
> >>>>>> feature creep is significant.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Mon, Jan 10, 2022 at 6:17 AM Andor Molnar <an...@apache.org>
> wrote:
> >>>>>>
> >>>>>>> Thanks for all the feedback and concerns folks. I’m trying
> organize them
> >>>>>>> in bullet points. Order is random, not importance.
> >>>>>>>
> >>>>>>> 1) Licence. I’m not familiar with dual-licensing either. Maybe we
> need
> >>>>>>> somebody with better Apache knowledge around this or ask the legal
> team,
> >>>>>>> I’m not sure. Hope this won’t be a blocker for logback.
> >>>>>>>
> >>>>>>> 2) Compatibility with other projects. "It has taken a long time,
> but it
> >>>>>>> appears that the wider big data
> >>>>>>> ecosystem is coming around to Log4J 2.”
> >>>>>>>
> >>>>>>> The way I see it and to be honest I'm almost always a
> “go-with-the-flow”
> >>>>>>> guy especially when comes to Hadoop, but the recent fiasco is a
> good
> >>>>>>> example of how bad idea it could be sometimes. Thanks Lord that
> ZooKeeper
> >>>>>>> still hasn’t moved to lo4j2 yet which saved me tons of working
> hours in my
> >>>>>>> employer.
> >>>>>>>
> >>>>>>> 3) Functionality of log4j2. In a nutshell: YAGNI. You don’t need to
> >>>>>>> implement or prepare for something which you don’t need _at the
> moment_.
> >>>>>>> That was my main intention of moving towards logback. Simple,
> fast, enough.
> >>>>>>>
> >>>>>>> 4) Performance. slf4j+logback outperforms basically everything:
> >>>>>>>
> https://stackoverflow.com/questions/11359187/why-not-use-java-util-logging
> >>>>>>> I haven’t verified it myself, so this might not be rock solid
> advantage.
> >>>>>>> Based on the article and given the amount of work needed to
> replace the
> >>>>>>> logging facade SLF4j with something else like j.u.l. is not the
> train I
> >>>>>>> originally wanted to jump on.
> >>>>>>>
> >>>>>>> So, I believe the question in this topic is “which default SLF4j
> logging
> >>>>>>> implementation shall ZK ship by default?”
> >>>>>>>
> >>>>>>> 5) Backward compatibility. That’s something I still need to work
> on.
> >>>>>>> Logback config translator is pretty neat:
> >>>>>>> https://logback.qos.ch/translator/ so, upgrading existing config
> files
> >>>>>>> should not be a problem. Additionally we keep log4j1 still an
> option as the
> >>>>>>> backend.
> >>>>>>>
> >>>>>>> Apologies I didn’t have time to take a look at slf4j-simple for
> our tests
> >>>>>>> yet, but looks like this option has already got support from
> multiple folks
> >>>>>>> in the community, so worth a shot.
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>>
> >>>>>>> Andor
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> On 2022. Jan 7., at 21:18, Patrick Hunt <ph...@apache.org> wrote:
> >>>>>>>>
> >>>>>>>> On Fri, Jan 7, 2022 at 12:10 PM Ted Dunning <
> ted.dunn...@gmail.com>
> >>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> I have been watching the private and public mailing lists for
> Apache
> >>>>>>>>> Logging as part of $dayjob as well.
> >>>>>>>>>
> >>>>>>>>> I read the mood there differently. The most recent comment I
> remember
> >>>>>>> was a
> >>>>>>>>> confirmation that "no bugfixes or security patches are planned
> for
> >>>>>>> log4j1".
> >>>>>>>>>
> >>>>>>>>> Log4j2 really is much larger than necessary. This is, in my
> opinion,
> >>>>>>> the
> >>>>>>>>> root cause of the recent farago.
> >>>>>>>>>
> >>>>>>>>> But having a cutaway by using slf4j is a very reasonable
> position to
> >>>>>>> take
> >>>>>>>>> there. Customers can use log4j2 if they want to or opt for
> simpler
> >>>>>>> systems.
> >>>>>>>>> Our default can be as simple as we like (even just util.logging).
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> That is a really good point Ted, one that came to mind a couple
> weeks
> >>>>>>> ago
> >>>>>>>> but I never circled back on - why are we not using util.logging by
> >>>>>>> default?
> >>>>>>>> Assuming end users can configure (slf4j) whatever they want.
> Perhaps we
> >>>>>>>> could even ship "samples" for the various options if there is
> >>>>>>> interest...
> >>>>>>>>
> >>>>>>>> Regards,
> >>>>>>>>
> >>>>>>>> Patrick
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> On Fri, Jan 7, 2022 at 9:57 AM Patrick Hunt <ph...@apache.org>
> wrote:
> >>>>>>>>>
> >>>>>>>>>> ...
> >>>>>>>>>>
> >>>>>>>>>> I also see that there is interest (upstream/apache I mean) in
> >>>>>>>>>> resurrecting log4j1 - imo that could also be a good path for us.
>
>

Reply via email to