Hi Murali,
I have always been a fan of slf4j, as it’s an abstraction layer between application code and the logging implementation you choose. I switched to using slf4j+logback in applications long ago,
but local installations should be able to select whatever logging implementation (presuming it’s supported, and most major ones are) for their logging needs.
it does appear that this community is switching to log4j2, and Spring Boot itself will be switching to that as the default logging implemetation in the near future. Those two endorsements alone
are probably enough reason to make a decision of log4j2 as a default logging solution.
I would still recommend considering using slf4j though, and I recently rediscovered that my last project used slf4j+log4j2, so I know from personal experience that it works fine. The real power
is that sites can select whatever logging implementation they desire by dropping in the necessary libraries, recompiling, and testing.
Thanks
Anthony
From: Tech-talk <tech-talk-bounces at aps.anl.gov>
On Behalf Of Matt Clarke via Tech-talk
Sent: Tuesday, December 14, 2021 1:42 AM
To: tech-talk at aps.anl.gov
Subject: Re: Log4Shell approaches
[EXTERNAL] This email originated from outside of FRIB
Hi.
As far as I understand, the security issue has been fixed so updating should be sufficient.
From the Logback page: “Fortunately, logback is unrelated to log4j 2.x and does not share its vulnerabilities.”
If I was cynical I might read that as “it probably has its own unique vulnerabilities which haven’t been found yet” ;)
Ultimately, like a lot of OSS, both projects seem to be maintained by a handful of core developers.
Cheers,
Matt
We were wondering if others had any recommendations on this. That is, should we continue using/migrating to log4j2 ( and hope the security issues are fixed
) or should we consider alternatives like logback etc. Any thoughts are appreciated.