t; >> But, if you are going to do a final 3.8 release, you might as well bump
> >> logback/slf4j
> >> just like the other branches
> >
> >
> > That’s the key takeaway for me I think. Easiest thing to do with this is to
> > backport the same upgra
Andor Molnar created ZOOKEEPER-4959:
---
Summary: Fix license files after logback/slf4j upgrade
Key: ZOOKEEPER-4959
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4959
Project: ZooKeeper
:39, Andor Molnar wrote:
>
> Thanks Christopher.
>
>> But, if you are going to do a final 3.8 release, you might as well bump
>> logback/slf4j
>> just like the other branches
>
>
> That’s the key takeaway for me I think. Easiest thing to do with this is to
Thanks Christopher.
> But, if you are going to do a final 3.8 release, you might as well bump
> logback/slf4j
> just like the other branches
That’s the key takeaway for me I think. Easiest thing to do with this is to
backport the same upgrade patch that we did for master/3.9. I’ll
Christopher might have
> some concerns. Let’s see if I understand it well.
>
> TL;DR
>
> - change logback-classic to test scope,
Except in the assemblies. It is still needed in at least
runtime to be included in an assembly.
> - use “flatten-maven-plugin” to drop it from published
y!
> >
> >> also drop the jar from release artifacts
> >
> > No jar is dropped but the test dependency entry in pom.xml. That is
> > there will be no `logback-classic` in pom.xml in the published jar.
> > So, external dependants are free to do whatever they want
zhu Wang wrote:
>
> Hi Andor,
>
> Thank you for the summary!
>
>> also drop the jar from release artifacts
>
> No jar is dropped but the test dependency entry in pom.xml. That is
> there will be no `logback-classic` in pom.xml in the published jar.
> So, externa
Hi Andor,
Thank you for the summary!
> also drop the jar from release artifacts
No jar is dropped but the test dependency entry in pom.xml. That is
there will be no `logback-classic` in pom.xml in the published jar.
So, external dependants are free to do whatever they want to do. We
could k
Thanks Kezhu, I can support this approach too, but Christopher might have some
concerns. Let’s see if I understand it well.
TL;DR
- change logback-classic to test scope,
- use “flatten-maven-plugin” to drop it from published pom (also drop the jar
from release artifacts)
- bump logback / slf4j
dependencies. I saw ZOOKEEPER-4820[1],
there are discussions to mark `logback-classic` as optional runtime
dependency[2]. I would suggest we change it to test scope and use
maven plugin "flatten-maven-plugin" to drop test dependencies from
published pom.xml to express the fact that
Thanks for the review. Let’s talk about the patch in more detail on GitHub.
> On Aug 13, 2025, at 13:21, Enrico Olivelli wrote:
>
> Il Mer 13 Ago 2025, 19:56 Andor Molnar ha scritto:
>
>> I’ve created a PR to attempt to replace logback with slf4j-simple. We do
>> hav
Il Mer 13 Ago 2025, 19:56 Andor Molnar ha scritto:
> I’ve created a PR to attempt to replace logback with slf4j-simple. We do
> have some test code relying on logback’s appenders, but we might be able to
> replace it with a basic output stream.
>
> https://github.com/apache/zook
I’ve created a PR to attempt to replace logback with slf4j-simple. We do have
some test code relying on logback’s appenders, but we might be able to replace
it with a basic output stream.
https://github.com/apache/zookeeper/pull/2293
ptal.
Andor
> On Aug 12, 2025, at 15:58, Christop
Andor Molnar created ZOOKEEPER-4957:
---
Summary: Replace logback with slf4j-simple on branch-3.8 due to
upgrading issues
Key: ZOOKEEPER-4957
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4957
I would NOT ship with reload4j in new releases. That exists only as a
temporary workaround for the lack of patch support for log4j 1.2,
until one is able to update to log4j2 or something else. ZK is already
using something else (logback). Neither log4j 1.2 nor reload4j are
appropriate for use with
Yeah, I totally agree.
The plan to go forward after getting 3.9.4 out of the door is to either remove
logback from branch-3.8 and replace it with something simpler like slf4j-simple
or reload4j since we ship the logback dependency as an example. Though I’m not
sure if slf4j-simple is an option
nisms, so that if somebody was using a different
sfl4j runtime other than logback, then it probably won't work anymore
without additional changes on the user's part.
I think the switch on 3.9 is probably okay, but users should be warned
that their logging will probably break if they had u
Considering all of this I’ll upgrade logback + slf4j to 1.3/2.0 on the 3.9
branch today and proceed with the release. 3.9 is the current release line and
I think this step is still acceptable at this stage. I won’t do the same on the
stable (3.8) branch and we should talk about EoL’ing soon in
"The 1.2.x series for logback-core and logback-classic has been deprecated for
several years and is no longer maintained. As such, use of the 1.2.x series is
discouraged.”
"Logback version 1.3.15 is the latest in the 1.3.x series. It requires SLF4J
version 2.0.x and JDK 8. Please not
I cannot upgrade logback without upgrading slf4j as well. Build fails.
> On Aug 6, 2025, at 17:07, Patrick Hunt wrote:
>
> Is slf4j really needed for security?
>
> Only cve I see here is from 2018...
> https://www.slf4j.org/news.html
>
> Should we revert the slf4
f4j upgrade (1.7.30 -> 2.0.13) has higher impact, because it’s
> a major upgrade. Logback is just an example of how to do logging with
> ZooKeeper real life setups probably replace it with something else like
> log4j2. The logging facade (slf4j) could have bw incompatible changes that
>
Maybe the slf4j upgrade (1.7.30 -> 2.0.13) has higher impact, because it’s a
major upgrade. Logback is just an example of how to do logging with ZooKeeper
real life setups probably replace it with something else like log4j2. The
logging facade (slf4j) could have bw incompatible changes t
Is the only problem the minor "semantic" upgrade of logback in a fix
release of zk? That should be stable (contract wise) on the dependency,
right? Or is there some real impact, eg b/w incompat change visible to ZK
users? If the former that seems fine, if the latter then we have a hard
Sorry for the confusion, I picked 3.8 as an example, but logback/slf4j upgrades
haven’t been backported to 3.9 either. Therefore I created the following
backport PR:
https://github.com/apache/zookeeper/pull/2290
> "Why would they be applied to master and not to any active (relea
I'm confused - this thread started with "OWASP reports CVEs on the 3.8
branch and noticed in the PRs that we should only upgrade logback on the
master branch" - I read that as "some fixes on 3.9 are not backported to
3.8". But you are saying that this is not fixed (sti
Yeah, that would remove the burden of maintaining the 3.8 version line, but
3.9.x versions still don’t have logback and slf4j upgraded, still flagged by
the Owasp build and users will probably still complain about CVEs.
My question is what should we do on branches other than the master?
1
, that is basically my concern. I commented at
> > > > >
> > https://github.com/apache/zookeeper/pull/2290#issuecomment-3145955665
> > > > >
> > > > > On Fri, Aug 1, 2025, 18:43 Andor Molnar wrote:
> > > > >
> > > > >> Ch
r/pull/2290#issuecomment-3145955665
> > > >
> > > > On Fri, Aug 1, 2025, 18:43 Andor Molnar wrote:
> > > >
> > > >> Christopher raised concern about it in
> > > >>
> > > >>
> > >
> https://githu
gt; > On Fri, Aug 1, 2025, 18:43 Andor Molnar wrote:
> > >
> > >> Christopher raised concern about it in
> > >>
> > >>
> > https://github.com/apache/zookeeper/pull/2162#pullrequestreview-2037135095
> > >>
> > >> I suspect b
ed at
> > https://github.com/apache/zookeeper/pull/2290#issuecomment-3145955665
> >
> > On Fri, Aug 1, 2025, 18:43 Andor Molnar wrote:
> >
> >> Christopher raised concern about it in
> >>
> >>
> https://github.com/apache/zookeeper/pull/2162#pu
//github.com/apache/zookeeper/pull/2162#pullrequestreview-2037135095
>>
>> I suspect because SLF4j has to be major upgraded with logback 1.x -> 2.x
>> which should not be done in bugfix releases.
>>
>> I’m not sure. Maybe we should just add another Owasp suppression, but
095
>
> I suspect because SLF4j has to be major upgraded with logback 1.x -> 2.x
> which should not be done in bugfix releases.
>
> I’m not sure. Maybe we should just add another Owasp suppression, but that
> wouldn’t be appropriate either.
>
> Andor
>
>
>
>
Christopher raised concern about it in
https://github.com/apache/zookeeper/pull/2162#pullrequestreview-2037135095
I suspect because SLF4j has to be major upgraded with logback 1.x -> 2.x which
should not be done in bugfix releases.
I’m not sure. Maybe we should just add another Ow
That’s my understanding too, but looks like folks skipped even the 3.9 backport
in the case of logback.
Andor
> On Jul 30, 2025, at 16:36, Patrick Hunt wrote:
>
> My understanding, I thought the rule was to backport any patch to all of
> the active releases unless it
because OWASP reports CVEs on the
> 3.8 branch and noticed in the PRs that we should only upgrade logback on
> the master branch. Why is that?
>
> logback-core-1.2.13.jar (pkg:maven/ch.qos.logback/logback-core@1.2.13,
> cpe:2.3:a:qos:logback:1.2.13:*:*:*:*:*:*:*) : CVE-2024-12798, CVE-2024-12801
>
> Regards,
> Andor
>
>
>
Hi folks,
Currently I’m working on some backports, because OWASP reports CVEs on the 3.8
branch and noticed in the PRs that we should only upgrade logback on the master
branch. Why is that?
logback-core-1.2.13.jar (pkg:maven/ch.qos.logback/logback-core@1.2.13,
cpe:2.3:a:qos:logback:1.2.13
Chris Nauroth created ZOOKEEPER-4901:
Summary: Correct logback license information on master branch.
Key: ZOOKEEPER-4901
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4901
Project
Manisha created ZOOKEEPER-4894:
--
Summary: Update logback-core-1.2.13.jar to fix CVE-2024-12798
Key: ZOOKEEPER-4894
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4894
Project: ZooKeeper
Ananya Singh created ZOOKEEPER-4891:
---
Summary: Update logback to logback to 1.3.15
Key: ZOOKEEPER-4891
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4891
Project: ZooKeeper
Issue
ZhangJian He created ZOOKEEPER-4831:
---
Summary: update slf4j from 1.x to 2.0.13, logback to 1.3.14
Key: ZOOKEEPER-4831
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4831
Project: ZooKeeper
Bhavya hoda created ZOOKEEPER-4825:
--
Summary: CVE-2023-6378 is present in the current logback version
(1.2.13) and hence we need to upgrade to 1.4.12
Key: ZOOKEEPER-4825
URL: https://issues.apache.org/jira
PJ Fanning created ZOOKEEPER-4820:
-
Summary: zookeeper pom leaks logback dependency
Key: ZOOKEEPER-4820
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4820
Project: ZooKeeper
Issue
Ivgeni created ZOOKEEPER-4778:
-
Summary: Patch jetty, netty, and logback to remove high severity
vulnerabilities
Key: ZOOKEEPER-4778
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4778
Project
Thomas Mortagne created ZOOKEEPER-4763:
--
Summary: Logback dependency should be scope provided/test
Key: ZOOKEEPER-4763
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4763
Project: ZooKeeper
Shinya Yoshida created ZOOKEEPER-4557:
-
Summary: MDC for myid is missing in children threads due to log4j
vs logback incompatibility
Key: ZOOKEEPER-4557
URL: https://issues.apache.org/jira/browse/ZOOKEEPER
qiang Liu created ZOOKEEPER-4465:
Summary: zooinspector logback pattern config add escape for '('
and ')'
Key: ZOOKEEPER-4465
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4465
Hi folks,
I’ve created the second and hopefully final patch for the Logback migration
covering the rest of maven projects. Please review.
https://github.com/apache/zookeeper/pull/1807
Regards,
Andor
I might be able to look into doing a log4j2 patch if there was interest in
that. But, I don't want to spend a lot of time doing that if the community
has already decided on logback.
On Thu, Jan 20, 2022 at 4:27 AM Szalay-Bekő Máté
wrote:
> I think we are slowly converging toward the f
I think we are slowly converging toward the following conclusion (at least
this is how I see it).
- We want to make either Log4j2 or Logback as the default log engine.
- We would provide some blogpost / documentation / how-to about how to
change the default log engine. (even as simple as
Thanks for the quick review Chris.
I agree with the second part of your e-mail completely. I’m not sure either
that the community has given a thumbs-up for logback, but I wanted to finalize
my patch sooner, because I have other duties to take care of.
I feel like logback is generally
ode perspective,
but it sounds like the discussion of direction is not necessarily settled
here. Can others who have raised red flags please clarify the degree of
their objections? Is anyone actually -1 on a move to Logback? For my part,
even though I raised objections, I'm OK proceeding with L
I’m done with all the changes that I wanted to include in the first logback
patch.
Most of Chris’ feedback has also been addressed as well as the licensing
changes.
We have binary distribution which includes the logback jar, so I added EPL v1.0
to LINCENSE.txt and mentioned Logback in the
I believe that the primary contributor to logback was highly skeptical that
the recent problems could possible affect logback. That isn't a good
attitude for security problems.
It isn't just a matter of patch rate. There is also the question of
community size. Is logback effectively
While it has had recent activity, it is notable that logback only recently
became active again for patches to the stable 1.2 releases. After several
releases in early 2017, it did not have a stable release for over four
years between 31-Mar-2017 (v1.2.3) and 19-Jul-2021 (v1.2.4).
On Tue, Jan 18
Yes. It looks like logback is still actively being developed. 1.2 had a
release in December. The 1.3 line is still alpha and has also seen recent
releases (interestingly, it requires at least Java 9 to build, but will run
on Java 8, which is similar to what I had recommended for ZK in a different
I agree with you completely and this is crucial for logback too, so
correct me if I'm wrong. Logback is current and actively maintained. Is
that correct?
Andor
On Tue, 2022-01-18 at 12:43 -0500, Christopher wrote:
> I do think these are more good reasons to adopt
> something that is
ussions about resuming
> log4j1 project (in the Apache incubator), also current users could
> probably use reload4j fork
>
> >
> > Which pushes us to move off from log4j1 sooner rather than later.
> Considering the options and the work I’ve already done on this front, I
&g
tor), also current users could
probably use reload4j fork
>
> Which pushes us to move off from log4j1 sooner rather than later. Considering
> the options and the work I’ve already done on this front, I would stick with
> ‘logback’ as the default logging backend for ZooKeeper an
flaw in the Chainsaw component of Log4j 1
can lead to malicious code execution.
Which pushes us to move off from log4j1 sooner rather than later. Considering
the options and the work I’ve already done on this front, I would stick with
‘logback’ as the default logging backend for ZooKeeper and
re more important in
production than they are in the build/test environment. But, I'm not going
to champion using a separate implementation for tests than what is shipped
in the tarball. I just wanted to explain that it was possible to do that,
if you wanted.
> At this point I believe t
e 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 framewo
lematic. 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 t
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.
goes for logback.
Andor
> On 2022. Jan 12., at 16:06, Andor Molnar wrote:
>
> Ouch…
> JUL doesn’t have MDC support.
>
>
>
>> On 2022. Jan 12., at 12:48, Andor Molnar wrote:
>>
>> Thanks Chris and Christopher for resolving the licensing issue.
>>
pect 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
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
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 wrote:
>
> I would add one more point. Logback has roughly benevolent dictator
> governance, Log4j is Apache. During t
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"
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 t
ot 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.
>
> I'm not a lawyer, but I'm pretty su
with better Apache knowledge around this or ask the legal team, I’m
> not sure. Hope this won’t be a blocker for logback.
I'm not a lawyer, but I'm pretty sure we can include a project under a
permitted license, regardless of whether the project is made available
under other license terms as
k 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
> 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
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 Hadoo
On Fri, Jan 7, 2022 at 12:10 PM Ted Dunning 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
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 necess
+1 to commit
>> Andor's patch and get rid of log4j1.
>>
>> Enrico
>>
>> Il Gio 6 Gen 2022, 20:38 Chris Nauroth ha scritto:
>>
>> > Happy New Year, and thank you for driving this, Andor!
>> >
>> > I am somewhat hesitant about swit
; > Happy New Year, and thank you for driving this, Andor!
> >
> > I am somewhat hesitant about switching direction to Logback:
> > - First, I agree with points already raised by Christopher.
> > - A major reason that my prior work to migrate to Log4J 2 in
> ZOOKEEPER-2342
to log4j2?
Personally I don't have much time next week to help, so I am +1 to commit
Andor's patch and get rid of log4j1.
Enrico
Il Gio 6 Gen 2022, 20:38 Chris Nauroth ha scritto:
> Happy New Year, and thank you for driving this, Andor!
>
> I am somewhat hesitant about s
Happy New Year, and thank you for driving this, Andor!
I am somewhat hesitant about switching direction to Logback:
- First, I agree with points already raised by Christopher.
- A major reason that my prior work to migrate to Log4J 2 in ZOOKEEPER-2342
stalled out years ago is backward
Hi folks,
Happy New Year!
Logback patch is now ready for review:
https://github.com/apache/zookeeper/pull/1793
Thanks,
Andor
> On 2021. Dec 21., at 20:44, Brent wrote:
>
> Thank you for the details Andor. It sounds like you have a good plan in
> place for doing the migration
n Tue, Dec 21, 2021 at 3:27 AM Enrico Olivelli wrote:
> Andor,
>
> Il giorno mar 21 dic 2021 alle ore 12:25 Andor Molnar
> ha
> scritto:
>
> > Thanks for the feedback Brent.
> >
> > I currently work on the logback patch and identified the following steps
> >
Andor,
Il giorno mar 21 dic 2021 alle ore 12:25 Andor Molnar ha
scritto:
> Thanks for the feedback Brent.
>
> I currently work on the logback patch and identified the following steps
> for migration:
> - Replace log4j references with logback counterparts in pom.xml,
> - R
Thanks for the feedback Brent.
I currently work on the logback patch and identified the following steps for
migration:
- Replace log4j references with logback counterparts in pom.xml,
- Refactor unit tests which depend on log4j: they create a custom
ByteArrayOutputStream for capturing log
ookeeper/pom.xml
On Sat, Dec 18, 2021 at 9:33 PM Brent wrote:
> Apologies if this is repeated information (I sent some of this to the user@
> mailing list).
>
> I understand the arguments for/against Log4j 1.x and won't repeat them all
> here. It seems like there's still
Apologies if this is repeated information (I sent some of this to the user@
mailing list).
I understand the arguments for/against Log4j 1.x and won't repeat them all
here. It seems like there's still some debate between Log4j2 vs. Logback
too. Does anyone have a feel for how much eff
s is not the best timing for
> log4j2.
>
> Anyway, the main advantage I see for logback is that it's closer to
> log4j1, hence probably easier to migrate to.
>
> ZooKeeper already uses SLF4j so, as you suggested, we should follow the
> facade / default logging backend
Agreed. My choice is not based on the recent vulnerabilities. There
probably more to come by the way, so this is not the best timing for
log4j2.
Anyway, the main advantage I see for logback is that it's closer to
log4j1, hence probably easier to migrate to.
ZooKeeper already uses SLF4j s
I think it would be a mistake to use the recently reported
vulnerability as a basis for migrating to logback. Any dependency can
have a vulnerability, and logback is not substantially different. No
dependency is going to be guaranteed vulnerability-free. Switching on
that basis is a wild goose
I think it is good to use Sl4j and provide the logback implementation.
This way users can use whatever framework they want to use
Enrico
Il giorno mer 15 dic 2021 alle ore 12:46 Andor Molnar ha
scritto:
> https://issues.apache.org/jira/browse/ZOOKEEPER-4427
>
>
> On Wed, 2021-12
Olivelli wrote:
> > +1
> >
> > Would you like to submit a PR ?
> > Then we can release 3.8.0
> >
> > Enrico
> >
> > Il giorno mer 15 dic 2021 alle ore 12:04 Flavio Junqueira
> >
> > ha scritto:
> >
> > > We use logback
Andor Molnar created ZOOKEEPER-4427:
---
Summary: Migrate to Logback
Key: ZOOKEEPER-4427
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4427
Project: ZooKeeper
Issue Type: Improvement
nqueira
>
> ha scritto:
>
> > We use logback in Pravega, it works fine for us. I'd be ok with the
> > change.
> >
> > -Flavio
> >
> > > On 15 Dec 2021, at 12:02, Andor Molnar wrote:
> > >
> > > Hi ZK folks,
> > >
> &
+1
Would you like to submit a PR ?
Then we can release 3.8.0
Enrico
Il giorno mer 15 dic 2021 alle ore 12:04 Flavio Junqueira
ha scritto:
> We use logback in Pravega, it works fine for us. I'd be ok with the change.
>
> -Flavio
>
> > On 15 Dec 2021, at 12:02, Andor Mo
We use logback in Pravega, it works fine for us. I'd be ok with the change.
-Flavio
> On 15 Dec 2021, at 12:02, Andor Molnar wrote:
>
> Hi ZK folks,
>
> What do you think about migrating ZK to logback?
> The idea just crossed my mind due to the recent turbulence with lo
Hi ZK folks,
What do you think about migrating ZK to logback?
The idea just crossed my mind due to the recent turbulence with log4j.
Checking some migrating guides, it doesn’t seem the end of the world.
Andor
96 matches
Mail list logo
