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 >> JUnit in Action, Second Edition >> Spring Batch in Action >> 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 >> JUnit in Action, Second Edition >> Spring Batch in Action >> 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 >> JUnit in Action, Second Edition >> Spring Batch in Action >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory > > > > -- > Matt Sicker <[email protected]>
