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>
