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]>
