In 3.x, we can remove a bunch of Logger methods thanks to lambda methods. I'm still working on my personal CDI-light experiment (effectively CDI minus decorators/interceptors/observers/events), though based on the amount of code it has exploded into, I'm still wondering whether or not the end result will be useful (right now, it's effectively a simplified version of CDI, though once I'm able to start refactoring Configuration based on it, I'll be able to tell if this is worth merging or not). I'll be working more on that again starting next week (yes, programming is also a hobby of mine during PTO :D).
As for the overall 3.0 story, what I'd love to see in general is the proper modularization of things as we've done some work toward in master already. Simplifying the build setup to require less versions of Java to compile everything would be great. API cleanup for everything marked deprecated for 3.0 (including some deprecated for 2.0 APIs that were never removed; go see Marker). As for package names, if we actually do try to simplify the Logger API or remove deprecated bits at least, then we'd likely need a separate package name and bridge for 2.x. And for a bonus chore task: unit test cleanup! I have a task for upgrading to JUnit 5 in our tests (while leaving a JUnit 4 logging rule available for 4.x users), and that seems like a great opportunity to rename test log4j config files to be more consistent with their tests and seeing if there are any untested configuration scenarios. I'd already be working on this if I weren't busy experimenting with the CDI-light thing. Of course, this task is not specific to 3.0 but generally more specific to when we changed our Java version baseline to 1.8. On Mon, 16 Dec 2019 at 11:03, Ralph Goers <[email protected]> wrote: > > > > > On Dec 16, 2019, at 9:42 AM, Raman Gupta <[email protected]> wrote: > > > > If there are API incompatibilities, an slf4j-like 2.x api bridge to > > 3.x would probably be the way to go. > > > > Its been a while since I looked at it, but IIRC, while implementing > > the Kotlin logger (https://logging.apache.org/log4j/kotlin/), I did > > note some things that it would be nice to change in the API -- see > > https://github.com/apache/logging-log4j-kotlin/blob/master/log4j-api-kotlin/src/main/kotlin/org/apache/logging/log4j/kotlin/KotlinLogger.kt#L51-L64. > > > > That being said, to make a wider point, if 3.0 is gonna by JDK11+, we > > could consider promoting lambda-based logging, like the Kotlin logger > > does, as a first-class log4j3 API. The advantage of a lambda-based > > logger is no more need for callers to do if-logger-level-enabled > > checks or to use the messy parameterized methods. > > > > Regards, > > Raman > > > Thanks for the input. > > The current log4j 2 API already supports lambdas. Are you proposing that we > do something different? What would that look like? > > FWIW, the idea that we would have to bridge the Log4j 2 API to a Log4j 3 > implementation doesn’t make sense to me. I would think that would annoy > users. The Log4j 3 implementation needs to work with the Log4j 2 API. The > problem Gary is highlighting is that having both the jars for the Log4j 2 API > and Log4j 3 API would mean the package structure would need to be different > between them. > > Instead, I would prefer that the Log4j 3 API be backward compatible with the > Log4j 2 API. > > Ralph -- Matt Sicker <[email protected]>
