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 <garydgreg...@gmail.com> 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 <garydgreg...@gmail.com>
> 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: garydgreg...@gmail.com | ggreg...@apache.org
>> 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: garydgreg...@gmail.com | ggreg...@apache.org
> 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: garydgreg...@gmail.com | ggreg...@apache.org
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
