Plugin builders

[Gary Gregory]

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

[Matt Sicker]

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.

Post by Gary Gregory
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
--
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

[Ralph Goers]

As I’ve said previously, I really dislike having two patterns for creating plugins.

Ralph

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

[Gary Gregory]

Right, it seems confusing and does not send a clear message on how to author your plugins.  Can we pick one way?

Gary

<div>-------- Original message --------</div><div>From: Ralph Goers <***@dslextreme.com> </div><div>Date:09/14/2014 13:35 (GMT-05:00) </div><div>To: Log4J Developers List <log4j-***@logging.apache.org> </div><div>Subject: Re: Plugin builders </div><div>
</div>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 <***@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 <***@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: ***@gmail.com | ***@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]

I know, JavaScript!

Post by Gary Gregory
Right, it seems confusing and does not send a clear message on how to
author your plugins. Can we pick one way?
Gary
-------- Original message --------
From: Ralph Goers
Date:09/14/2014 13:35 (GMT-05:00)
To: Log4J Developers List
Subject: Re: Plugin builders
As I’ve said previously, I really dislike having two patterns for creating
plugins.
Ralph
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.

Post by Gary Gregory
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
--
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

--