I have to admit I no longer have a clue how the plugins are created. The javadoc in AbstractConfiguration still talks about the original annotations but i’m not really sure where the code that constructs the factory or builder parameter lists moved to. can you provide a little help?
Ralph On Jun 1, 2014, at 4:13 PM, Matt Sicker <[email protected]> wrote: > Alright, I've committed what I was talking about before in regard to builder > classes and fields. The new @PluginBuilderAttribute annotation could be > extended to allow using a setter method as well, but I think it's fine for > now to just use fields. > > Anyway, using this idea, there's no longer a need to work around the > limitations of annotations for specifying default values. > > > On 1 June 2014 10:11, Gary Gregory <[email protected]> wrote: > On Sat, May 31, 2014 at 9:48 PM, Ralph Goers <[email protected]> wrote: > 1. That isn't consistent. > 2. If someone wanted to set the default value of a Log4j component via a > system property it wouldn't work. That said, I'm not sure how great a benefit > that actually is. > > To be honest, I think I actually would prefer > > @PluginAttribute("foo") @IntParameterDefault(1) int foo > > It just seems forced to have multiple plugin attribute types just so the > default value is strongly typed. > > Yes, I think this is the change I and others have been proposing. > > Gary > > > Ralph > > > On May 31, 2014, at 5:56 PM, Gary Gregory <[email protected]> wrote: > >> Well if you do not want strong typing, use a String for foo. >> >> Right? >> >> Gary >> >> >> -------- Original message -------- >> From: Ralph Goers >> Date:05/31/2014 20:38 (GMT-05:00) >> To: Log4J Developers List >> Subject: Re: PluginAttribute#defaultEnum()? >> >> Gary, I know you said you didn't like >> >> @PluginAttribute(name="foo", defaultValue="1") int foo >> >> But after looking at >> http://maven.apache.org/plugin-tools/maven-plugin-annotations/apidocs/org/apache/maven/plugins/annotations/Parameter.html >> I am wondering if that isn't the best way to go. Doing that would allow the >> default value to be something like ${sys:fooDefault} which you can't do with >> strong typing. >> >> Ralph >> >> Sent from my iPad >> >> On May 31, 2014, at 4:25 PM, Ralph Goers <[email protected]> wrote: >> >>> Why wouldn't you do >>> >>> @PluginAttributeInt(value="foo", defaultValue=1) int foo >>> >>> ? >>> >>> That said, I'm really not crazy about this. I wish you could do >>> >>> @PluginAttribute<Integer>(value="foo", defaultValue=1) int foo >>> >>> Ralph >>> >>> Sent from my iPad >>> >>> On May 31, 2014, at 12:50 PM, Gary Gregory <[email protected]> wrote: >>> >>>> So the bummer is that this redundant with the arg type in the signature: >>>> >>>> @PluginAttributeInt (value="foo", defaultInt=1) int foo >>>> >>>> We should also pick up the attribute name by reflection if it is missing >>>> from the annotation. >>>> >>>> But you'd only need it to spec a default value. So could we keep >>>> PluginAttribute with only a value and then have an annotation for each >>>> default value type? @DefaultInt and so on..? >>>> >>>> Ideally: >>>> >>>> @PluginAttribute() @DefaultInt (1) int foo >>>> >>>> Thoughts? >>>> >>>> Gary >>>> >>>> >>>> -------- Original message -------- >>>> From: Paul Benedict >>>> Date:05/30/2014 22:15 (GMT-05:00) >>>> To: Apache Log4J Developers >>>> Subject: Re: PluginAttribute#defaultEnum()? >>>> >>>> Totally cleaner. >>>> >>>> On May 30, 2014 8:58 PM, "Gary Gregory" <[email protected]> wrote: >>>> On Fri, May 30, 2014 at 9:39 PM, Paul Benedict <[email protected]> >>>> wrote: >>>> I think you guys are better off doing separate annotations to do strong >>>> typing. You could use a stereotyping pattern like Bean Validation spec. >>>> >>>> public @interface PluginAttribute ... >>>> >>>> Then annotate other annotations with that: >>>> @PluginAttribute >>>> public @interface IntPluginAttribute >>>> >>>> >>>> I did propose that earlier ;-) It seems much cleaner... >>>> >>>> Gary >>>> >>>> See how the Been Validation spec works to copy their pattern. >>>> >>>> On May 30, 2014 7:55 PM, "Gary Gregory" <[email protected]> wrote: >>>> Hm... you cannot use Enum in the return type for an annotation attribute, >>>> only an actual enum, like RetentionPolicy. So it seems a no-go. >>>> >>>> Gary >>>> >>>> >>>> On Fri, May 30, 2014 at 4:24 PM, Matt Sicker <[email protected]> wrote: >>>> I had the same hold-up when thinking about adding that, too. How about >>>> RetentionPolicy.SOURCE? Or ElementType.TYPE? Something annotation-related >>>> like that. >>>> >>>> >>>> On 30 May 2014 13:12, Gary Gregory <[email protected]> wrote: >>>> I added PluginAttribute#defaultClass() since we can have a Class has an >>>> attribute value. >>>> >>>> One can also have an Enum as an attribute value, but what default should >>>> be use? >>>> >>>> Gary >>>> >>>> -- >>>> 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]> >>>> >>>> >>>> >>>> -- >>>> 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]>
