You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Gary Gregory <ga...@gmail.com> on 2014/09/14 16:51:35 UTC
Plugin builders
Seeing the last commit go by for a builder on the console appender made me
wonder if we really want this pattern considering the size cost in extra
code. So this is just a sanity check that we are not making this fancier
than it needs to be considering... what? That this would only be used for
programmatic configuration by tests and other apps. Are the builders also
used by the configuration code?
Gary
--
E-Mail: garydgregory@gmail.com | ggregory@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
Re: Plugin builders
Posted by Ralph Goers <ra...@dslextreme.com>.
As I’ve said previously, I really dislike having two patterns for creating plugins.
Ralph
On Sep 14, 2014, at 10:05 AM, Matt Sicker <bo...@gmail.com> wrote:
> The builders are used first if they're available, falling back to the factory. However, with more automatic checking of parameters and such, it might not even be all that useful to have the builders anymore. It would be good to have at least some createDefaultAppender() methods and such for our own usage.
>
> Either way, as long as there's enough metadata to build the plugins reflectively, we should be good to go. Adding a feature like automatic XSD generation for the strict mode would be pretty neat for instance.
>
> On 14 September 2014 09:51, Gary Gregory <ga...@gmail.com> wrote:
> Seeing the last commit go by for a builder on the console appender made me wonder if we really want this pattern considering the size cost in extra code. So this is just a sanity check that we are not making this fancier than it needs to be considering... what? That this would only be used for programmatic configuration by tests and other apps. Are the builders also used by the configuration code?
>
> Gary
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> 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 <bo...@gmail.com>
Re: Plugin builders
Posted by Matt Sicker <bo...@gmail.com>.
The builders are used first if they're available, falling back to the
factory. However, with more automatic checking of parameters and such, it
might not even be all that useful to have the builders anymore. It would be
good to have at least some createDefaultAppender() methods and such for our
own usage.
Either way, as long as there's enough metadata to build the plugins
reflectively, we should be good to go. Adding a feature like automatic XSD
generation for the strict mode would be pretty neat for instance.
On 14 September 2014 09:51, Gary Gregory <ga...@gmail.com> wrote:
> Seeing the last commit go by for a builder on the console appender made me
> wonder if we really want this pattern considering the size cost in extra
> code. So this is just a sanity check that we are not making this fancier
> than it needs to be considering... what? That this would only be used for
> programmatic configuration by tests and other apps. Are the builders also
> used by the configuration code?
>
> Gary
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@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
>
--
Matt Sicker <bo...@gmail.com>