I'll point to the bottom of that page in the BeanJUnit4Runner class which demonstrates how simple it was to integrate into JUnit. The next phase's complicated part will be linking configuration files to bean creation along with refactoring Configuration classes to use the new APIs. I'll point to [1] where these runners can get far more complicated.
[1]: https://github.com/spring-projects/spring-framework/blob/master/spring-test/src/main/java/org/springframework/test/context/junit4/SpringJUnit4ClassRunner.java On Sun, 23 Feb 2020 at 17:54, Matt Sicker <boa...@gmail.com> wrote: > > I've gathered together all the working subset of where I'm at and > committed it to the newly created "mean-bean-machine" branch. There > are numerous TODO comments left in there, but after so long, I figured > it was more important to show a work in progress rather than continue > to vaguely talk about it. > > GitHub diff page: > https://github.com/apache/logging-log4j2/compare/mean-bean-machine > > On Sun, 23 Feb 2020 at 15:11, Matt Sicker <boa...@gmail.com> wrote: > > > > 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> > > > > -- > Matt Sicker <boa...@gmail.com> -- Matt Sicker <boa...@gmail.com>
