Regarding unit tests and upgrading from junit 4 to junit 5, I've written some automation to ease the transition, including conversion from org.junit.Assert to the AssertJ[1] library. Thisdecouples assertions from the framework, and takes advantage of tab completion for more specific tests with less code and complexity. Do others have experience with AssertJ and want to use it in log4j?
We're working on splitting the automation into an isolated OSS project this week. A snippet from the readme: -assertTrue(continents.size() == 7); +assertThat(continents).hasSize(7); (Before) Test failures like the following can be quite frustrating to debug: `Expected :true Actual :false `(After) By tweaking the assertion code slightly, the failure message can be vastly improved, allowing an engineer to quickly diagnose what went wrong - perhaps they left a `foo` in recently: `java.lang.AssertionError: Expected size:<7> but was:<8> in: <["Africa", "Asia", "North America", "South America", "Antarctica", "Australia", "foo"]>` 1. https://joel-costigliola.github.io/assertj/ -ck On Mon, Dec 16, 2019, at 12:58, Matt Sicker wrote: > 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]> >
