Although I see what you are doing in the test it isn’t clear to me what impact it will have on Log4j and plugins. I am looking forward to seeing examples of that.
Ralph > On Feb 23, 2020, at 1:22 PM, Matt Sicker <boa...@gmail.com> wrote: > > Yes, the thing I've been talking about for the past few months, after > several iterations and a couple rewrites, is almost ready for review. > In preparation for that, I've been refactoring the existing unit tests > based on my recently written JUnit 4 runner that handles automatic > dependency injection of the test class itself (pretty neat integration > that nearly came for free with the SPI I've exposed so far). Based on > that, I figured I'd give a sneak preview of how the updated model > supports (note that I'm working on 100% backward compatibility with > the v2 annotations, and there still remains some work to integrate > this into the existing plugin system which allows for that code to be > replaced finally): > > https://gist.github.com/jvz/c71701a318dc225456bbb8a92627708a > > One thing you might notice if you're already familiar with CDI or > Spring is that this system is fairly similar, though it also provides > some additional support for dependency injection concepts that we > already use in Log4j (i.e., the builder class pattern) that I couldn't > find an equivalent for elsewhere. > > I'm still working on adding more tests today, and I'll try to remember > to update this gist later when I've added more locally. I'm also > working on adding documentation to things and some general finishing > touches before I push up a branch. As the code is all self-contained, > technically, this can also be done in master (it's how I've been > developing it locally, though I haven't commit anything other than > small things here and there that I've already pushed to master in the > past), but I'll first make it available in a branch for anyone > interested to take a look and offer feedback before merging. > Alternatively, I can keep a feature branch open while I continue the > next phase of the DI system where I start hooking it into log4j-core. > I'm not a big fan of long lived feature branches (more easy to gather > merge conflicts over time, and as we merge or rebase from master, that > generates tons of notification emails, or at least it did in the > past), but if that's the more appropriate place to do this, I'm open > to doing so. > > Also, neat features of the JUnit runner as opposed to using a JUnit > rule (which I tried first): > * Allows the test class to participate in dependency injection > * Allows the test methods to provide parameters which can also utilize > dependency injection > * Fits more naturally with the SPI as written so far > > -- > Matt Sicker <boa...@gmail.com> >
