Going back to this programmatic configuration topic, I agree with Ralph's idea of using Configuration/Node. Thus, a programmatic API would likely work via that idea so as not to cause problems with this sort of annotation.
On 9 July 2014 14:34, Ralph Goers <[email protected]> wrote: > Not necessarily Groovy specifically, but in general, yes. However, even > then it might be nicer to have a layer above that that creates the Nodes > and adds them to the hierarchy. I’m not really sure what that would look > like. I’d have to try to build something before I would know what would be > “friendly”. > > Ralph > > On Jul 9, 2014, at 11:03 AM, Matt Sicker <[email protected]> wrote: > > A Groovy DSL using closures would make a neat interface to creating the > Node hierarchy you're speaking of. Is that what you meant when you > mentioned this in the past? > > > On 9 July 2014 01:03, Ralph Goers <[email protected]> wrote: > >> IMO the proper, and recommended, way to do programmatic configuration is >> to implement a Configuration, the end result of which is a tree of Nodes. >> Doing that leverages everything we have to offer and is probably simpler >> to implement in the end. We should create a sample that shows how to do >> this. >> >> While creating Loggers, Appenders, etc manually is possible it is always >> going to be brittle as we are not going to guarantee that components won't >> change and thus the factory methods may have parameters added. This would >> be less of a problem with the builders Matt loves, but it is a complete >> non-issue when the plugin system does the work, which is why leveraging it >> should be our recommended approach. >> >> So I wouldn't worry about the validation if the plugin system is >> bypassed. If they want to manually create the components then they should >> also have to perform all the validation the plugin system provides, >> >> Ralph >> >> On Jul 8, 2014, at 9:53 PM, Gary Gregory <[email protected]> wrote: >> >> Actually, if the framework detects a "required" violation and logs a >> message, it should not call the create() method, so there would no double >> logging. >> >> It would then be up to the plugin author to decide what level of >> validation he or she wants: >> >> - Use the required annotation attribute and let the framework validate >> (and log) >> - Don't use the required annotation attribute and validate in the plugin >> (and log) >> - Use the required annotation attribute, let the framework validate (and >> log), AND provide validation (and logging) in the plugin for programmatic >> configs. >> >> So it does still make sense. >> >> The big question is should we use the required annotation attribute and >> remove all the validation and logging. This would be a nice clean up. The >> cases where people to programmatic configs would be the 20 of the 80/20 and >> since those users are more advanced, they should be able to better deal >> with calling create methods with non-garbage input, and if they do they >> should handle, NPEs and such. >> >> Thoughts? >> >> Gary >> >> >> On Tue, Jul 8, 2014 at 9:56 PM, Gary Gregory <[email protected]> >> wrote: >> >>> Hm... if the error logging takes place in the plugin framework, then it >>> should be removed from the create() methods, but then apps that do >>> programmatic configuration will not benefit from the error logging. We >>> would then need to either keep the current guard clauses (with no logging) >>> or remove the guard clauses and let the chips fall where they may with NPEs. >>> >>> Thoughts? >>> >>> Gary >>> >>> >>> On Mon, Jul 7, 2014 at 11:35 AM, Gary Gregory <[email protected]> >>> wrote: >>> >>>> Why don't we have a required flag? >>>> >>>> Using it and throwing an Exception when this condition is violated >>>> would avoid guard code like: >>>> >>>> @PluginFactory >>>> public static RegexFilter createFilter( >>>> @PluginAttribute("regex") final Pattern regex, >>>> @PluginAttribute("useRawMsg") final Boolean useRawMsg, >>>> @PluginAttribute("onMatch") final Result match, >>>> @PluginAttribute("onMismatch") final Result mismatch) { >>>> >>>> if (regex == null) { >>>> LOGGER.error("A regular expression must be provided for >>>> RegexFilter"); >>>> return null; >>>> } >>>> return new RegexFilter(useRawMsg, regex, match, mismatch); >>>> } >>>> >>>> ? >>>> >>>> -- >>>> 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 >>>> >>> >>> >>> >>> -- >>> 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 >>> >> >> >> >> -- >> 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]>
