One of the more noticeable impacts it will have is the ability to define all the various singleton objects and configuration-global objects in a more consistent fashion. This sort of thing will come during phase two where I integrate it into log4j-core as mentioned.
On Sun, 23 Feb 2020 at 15:06, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > 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> > > > > -- Matt Sicker <boa...@gmail.com>
