Ok, I'm fine with that. Remko On Thursday, January 30, 2014, Nick Williams <nicho...@nicholaswilliams.net> wrote:
> I agree. > > Nick > > On Jan 29, 2014, at 5:09 PM, Paul Benedict wrote: > > I would like to propose not doing anything on this subject until there is > a request from the community. It's probably way too easy to over-engineer > and devise solutions to problems that a small percentage (or zero?) of the > users will need. I am all for ingenuity and passion, but after GA occurs > and there's no experience with custom levels directly, we might get a > better idea what the "right" answer is. > > So slate this for 2.x in JIRA and let's get to GA. > > > On Wed, Jan 29, 2014 at 4:53 PM, Matt Sicker <boa...@gmail.com> wrote: > > Annotation processing is beyond over-engineered, yet it still lacks some > of the neat features from runtime annotation "processing". I've been > meaning to look more into it as it might be useful for injecting Loggers > using annotations. > > > On 29 January 2014 07:46, Remko Popma <remko.po...@gmail.com> wrote: > > > > On Wednesday, January 29, 2014, Nick Williams < > nicho...@nicholaswilliams.net> wrote: > > > On Jan 28, 2014, at 5:43 PM, Remko Popma wrote: > > I would really like everyone's feedback on this. I have two questions: > > 1. Does this fulfill everyone's requirements? > Another way of asking this is: would you use this in your own projects? > (If not, why not?) > > > Personally, no. I don't like the code generation for IDE integration > issues. I'd prefer an interface I wrote. > > > I'm not sure what you mean by IDE integration issues, but let's not lose > sight of why we are doing this in the first place: we want to provide > convenience methods to make custom levels as easy to use as built-in > levels. > I'm beginning to feel that we are adding additional requirements on top of > this that make it difficult to achieve our original goal... > > > 2. What do you think of this approach? > Obviously code generation has drawbacks. For one thing, IDE refactoring > tools don't work and API changes don't cause compile errors in the > generator itself, only in the generated code. (I plan to add a JUnit test > that generates a custom logger, compiles it and executes the custom logging > methods so we can at least catch issues during the build.) > The advantage is that it is open-ended and can deal with any custom level > users can dream up. > > Is this trade-off acceptable? > Are there other ways to solve this? > > > Also IMO, I would tend to steer away from only generating a concrete > class. The interface and implementation should be separate. Imagine a Log4j > fixing a bug in the generation code and releasing 2.0.1 or whatever. Now > the user has a generated implementation, so they can't /just/ upgrade their > Maven dependency. They /also/ have to re-generate their code. That's a > pain. However, with the interface and implementation separate, the > interface probably doesn't have to change, and the implementation will > change as soon as they fire up their app with the latest Log4j. > > Also, if you separate the interface and implementation, you can make the > generation of the interface optional. The user can /choose/ whether to > generate the interface or create the interface themselves. Then the > implementation generates at runtime. > > > My original intuition was also to start with a separate interface and > implementation but as I was thinking about "what is the simplest thing that > could possibly work?" I ended up with this design. Please don't dismiss > this solution just because it is based on a concrete class. > > Generating an implementation at runtime just seems so much more complex. > It involves inspecting the signature of every > >
