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>
