On Mon, Jun 2, 2014 at 9:50 PM, Matt Sicker <[email protected]> wrote:
> Part of this is to make it easier for other users to write their own > plugins easily. Another part of this is to reduce code duplication which is > very tedious and error-prone. > I'm all for that. > I really don't see how a builder class is more complicated than a method > with the same number of parameters as fields. > If your builder has a triplet of ivar/getter/setter for each factory parameter, then it's more code and more "complicated" than a single factory method with paramters. IMO. YMMV. The problem here is that I do want to be forced into one configuration style but OTOH I do not think it is good for us to provide two or three styles to do the same thing. We need to pick one. It' bad enough we have three different configuration file syntax formats. If Java had named parameters like many other languages, it wouldn't be an > issue! > Map<String, Object>! ;-) Just kidding. > > Another short-term issue we've had with this is that I didn't think of > re-using the existing plugin infrastructure to register the type > converters. We've already got similar "framework" things in all the other > types of plugins like string lookups, layouts, patterns, selectors, and the > logging-specific appenders and filters. > > The registries are short term solutions due to my lack of familiarity in > creating new plugin types. I agree, the registries add needless complexity > as the plugins provide the only registry necessary in log4j as far as I can > tell. > > Also, I think that the builders can help provide a way to configure log4j > in a Java DSL. That's a feature I'd like to see in the future. I hate > learning new configuration file formats all the time. Being able to > configure via Java or making a bunch of beans in a Spring XML (or Blueprint > XML in OSGi) is pretty common in larger projects. > > Really, what we need is some more iteration of ideas on how to best go > about doing this in a flexible way that's easy for us to develop and > maintain, and easy for users to use and extend. > To to follow the rest of Log4j, I could have a class with a bunch static inner classes all annotated with something like @TypeConverter and that would be it? Gary > > > On 2 June 2014 17:13, Remko Popma <[email protected]> wrote: > >> Does anyone else also have little alarm bells going off when seeing >> conversations like this? >> >> Before you'd accomplish this by simply coding the conversion in the >> factory method. Duplicate code would be factored out to utility classes >> like Strings etc and it was all pretty straightforward. >> >> Now we have a framework to do the same, with TypeConverters and >> Registries and Builders and Visitors. >> The gain is that we get the conversion from String to int "for free". >> (Except that it is not free, the complexity just moved somewhere else, and >> arguably became bigger.) >> Also, the builders allow us to name parameters when construction plugin >> objects in tests. >> >> The trade-off is that we have a whole lot more infrastructure. Not only >> is this more code and more complex than what we had before, but as with any >> framework, it makes assumptions on how things are done and in what order, >> and if you need to do something differently then the framework just gets in >> your way... >> So now we need to keep modifying the framework to handle these cases. >> >> I need to spend more time looking at the code, I'm basing a lot of this >> on the impression I have after reviewing the commit emails, but I'm really >> starting to think that the gains don't justify the drawbacks. >> >> Sent from my iPhone >> >> On 2014/06/03, at 6:06, Matt Sicker <[email protected]> wrote: >> >> We need to change the type converter registry to use the existing plugin >> registry/manager. That would make this a lot easier! I'll work on that >> sometime this week. I've been meaning to get to that (I have a TODO about >> it somewhere). >> >> >> On 2 June 2014 11:15, Gary Gregory <[email protected]> wrote: >> >>> If I want to register my own type converters with >>> >>> org.apache.logging.log4j.core.config.plugins.util.TypeConverters.registerTypeConverter(Class<?>, >>> TypeConverter<?>) >>> >>> when do I call it to make sure the configuration parsing picks up my >>> additions before it is to late? >>> >>> Gary >>> >>> -- >>> E-Mail: [email protected] | [email protected] >>> Java Persistence with Hibernate, Second Edition >>> <http://www.manning.com/bauer3/> >>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >>> Spring Batch in Action <http://www.manning.com/templier/> >>> Blog: http://garygregory.wordpress.com >>> Home: http://garygregory.com/ >>> Tweet! http://twitter.com/GaryGregory >>> >> >> >> >> -- >> Matt Sicker <[email protected]> >> >> > > > -- > Matt Sicker <[email protected]> > -- E-Mail: [email protected] | [email protected] Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
