I will preface my comments with the fact that I don’t use log4cxx and am primarily focused on Log4j 2. However, before I switched to Java I coded in C/C++ and supported a custom proprietary logging framework for a former employer.
With that out of the way, my understanding is that log4cxx was originally built with the goal of being somewhat consistent with Log4j 1.x. Log4j 2 didn’t adhere to that goal because it was felt that there were more “modern” ways to do things that would make user’s lives easier. As far as the configuration goes, the most notable impact is that the class attribute is no longer present because everything is a plugin. So if you want to upgrade log4cxx to mimic what Log4j 2 is doing, that would be a laudable goal but would probably be incompatible with the current behavior and warrant a new version. Again, although I am on the Logging PMC I don’t consider myself a log4cxx user, so my advice should be viewed accordingly. Ralph > On May 22, 2020, at 2:26 PM, Patrick Mills <patrick.mi...@cerberusftp.com> > wrote: > > First I wanted to say thank you to everyone who has worked to revive > log4cxx. And to those who have also worked to bring back the Windows side > with cmake and testing; it's a lot of work and very much appreciated. > > We've been using log4cxx for a while and have a few additions we'd like to > contribute. For this particular filter, we're wondering how the community > feels about the syntax and exact parity with log4j. > > In log4j, the map filter is a plugin, so you get syntax like: > <MapFilter onMatch="DENY" operator="and"> <KeyValuePair key="client.ip" > value="127.0.0.1"/> <KeyValuePair key="client.user" value="test2"/> > </MapFilter> > > While we could duplicate that syntax with modifications to domconfigurator, > it introduces a fair amount of one-off code and duplication. Our current > implementation leverages the existing filter parser and requires no changes > outside the filter itself: > <filter class="MapFilter"> <param name="client.ip" value="127.0.0.1" /> > <param name="client.user" value="test2" /> <param name="Operator" > value="AND" /> <param name="AcceptOnMatch" value="false" /> </filter> > > So my question is which does the log4cxx community prefer? Something that > minimizes code changes or something that more closely mirrors log4j; the > filter itself remains pretty much the same either way. > > Personally, I think it fits better into the filter parser, but I would > rather have this accepted into the code base than have something separate, > so I am willing to go either way before I submit the PR.
