I’ve used AssertJ before and really liked it. On Mon, Dec 16, 2019 at 12:10 Carter Kozak <cko...@ckozak.net> wrote:
> 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 <ralph.go...@dslextreme.com> > wrote: > > > > > > > > > > > > > On Dec 16, 2019, at 9:42 AM, Raman Gupta <rocketra...@gmail.com> > 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 <boa...@gmail.com> > > > -- Matt Sicker <boa...@gmail.com>
