Actually, as I look more closely into that, this is not something a user would have to call manually or anything like that. It is just a way to reset configuration. In older versions, it was done via JMX but in newer one it seems to be done differently.
There is still this (1) removed from the user's perspective. If it is still there when Cassandra starts (imagine that people would use old logback.xml from 5.0.5), then this log appears as Cassandra starts: 15:14:15,201 |-WARN in ch.qos.logback.core.model.processor.ImplicitModelHandler - Ignoring unknown property [jmxConfigurator] in [ch.qos.logback.classic.LoggerContext] with dozens of other logging configuration related outputs which just appear there when something is wrong. How do other people look at this? Curious what others think. Regards (1) https://github.com/apache/cassandra/pull/4432/files#r2439967712 On Fri, Oct 17, 2025 at 3:09 PM Štefan Miklošovič <[email protected]> wrote: > > Hi Michael, > > I think that the patch you are suggesting to merge is just a > cherry-pick of the patch applied in (1). There is technically nothing > wrong with it but one thing and that is that it removes this from > logback.xml (2) and eventually also this (3) as that functionality > seems to not be around after upgrading the libraries. > > I am not completely sure we can do this kind of change in a patch > release. If somebody uses / interacts with JMX to control things via > that, I do not think that we can just take it away from them like that > while they merely version bump from one patch release to another. > > Wondering how others look at this but this is how I do. > > Regards > > (1) https://issues.apache.org/jira/browse/CASSANDRA-20429 > (2) https://github.com/apache/cassandra/pull/4432/files#r2439967712 > (3) https://github.com/apache/cassandra/pull/4432/files#r2439975818 > > On Fri, Oct 17, 2025 at 11:59 AM Michael Morris <[email protected]> > wrote: > > > > It would be great if you could consider including > > https://github.com/apache/cassandra/pull/4432 in 5.0.6 to silence > > vulnerability scanning tools, if committers are agreeable and if its not > > too late. > > > > On 16/10/2025 17:56, Mick wrote: > > > I will pull this candidate and re-cut when CASSANDRA-20976 lands. > > > > > > Paulo, 4.1 didn't get cut as the reason for cutting 4.0.19 was > > > CASSANDRA-20848 which already is released in 4.1.10 > > > > > > > > > > > >> On 16 Oct 2025, at 18:17, Štefan Miklošovič <[email protected]> > > >> wrote: > > >> > > >> I am also for the re-staging with CASSANDRA-20976 in. It seems its > > >> merge is imminent. > > >> > > >> On Thu, Oct 16, 2025 at 3:59 PM Paulo Motta <[email protected]> wrote: > > >>> > > >>> Should we wait for CASSANDRA-20976 to land, since this is a user-facing > > >>> issue in 5.0? > > >>> > > >>> Also, is there any reason why we are releasing 4.0 and 5.0 but not 4.1 ? > > >>> > > >>> On Thu, Oct 16, 2025 at 2:56 AM Mick <[email protected]> wrote: > > >>>> > > >>>> > > >>>>> The vote will be open for 72 hours (longer if needed). Everyone who > > >>>>> has tested the build is invited to vote. Votes by PMC members are > > >>>>> considered binding. A vote passes if there are at least three binding > > >>>>> +1s and no -1's. > > >>>> > > >>>> > > >>>> > > >>>> +1 > > >>>> > > >>>> Checked > > >>>> - signing correct > > >>>> - checksums correct > > >>>> - source artefact builds (JDK 11+17) > > >>>> - binary artefact runs (JDK 11+17) > > >>>> - debian package runs (JDK 11+17) > > >>>> - debian repo runs (JDK 11+17) > > >>>> - redhat* package runs (JDK11+17) > > >>>> - redhat* repo runs (JDK 11+17) > > >>>> > > >>>> > >
