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
Post by Ralph GoersIMO 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
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
- 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
Post by Gary GregoryHm... 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
Post by Gary GregoryWhy don't we have a required flag?
Using it and throwing an Exception when this condition is violated would
@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);
}
?
--
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
--
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
--
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