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