)
> To: Log4J Developers List
> Subject: Re: PluginAttribute vs. IntPluginAttribute
>
> We can choose which attribute of the annotation to use based on the type
> the annotation is attached to. That wouldn't be too hard.
>
>
> On 26 May 2014 08:34, Gary Gregory wrote:
>
>> O
Date:05/26/2014 15:19 (GMT-05:00)
To: Log4J Developers List
Subject: Re: PluginAttribute vs. IntPluginAttribute
We can choose which attribute of the annotation to use based on the type
the annotation is attached to. That wouldn't be too hard.
On 26 May 2014 08:34, Gary Gregory wrote:
O
We can choose which attribute of the annotation to use based on the type
the annotation is attached to. That wouldn't be too hard.
On 26 May 2014 08:34, Gary Gregory wrote:
> On Mon, May 26, 2014 at 9:02 AM, Remko Popma wrote:
>
>>
>>
>>
>> On Mon, May 26, 2014 at 9:58 PM, Gary Gregory wrote:
>
On Mon, May 26, 2014 at 9:02 AM, Remko Popma wrote:
>
>
>
> On Mon, May 26, 2014 at 9:58 PM, Gary Gregory wrote:
>
>> A recent commit contains:
>>
>>
>>> +@PluginAttribute(value = "blocking", defaultValue = "true")
>>> final boolean blocking,
>>>
>>
>> Using a String default for a non
On Mon, May 26, 2014 at 9:58 PM, Gary Gregory wrote:
> A recent commit contains:
>
>
>> +@PluginAttribute(value = "blocking", defaultValue = "true")
>> final boolean blocking,
>>
>
> Using a String default for a non-string attribute seems like a punch in
> the eye ;-) This really feels
A recent commit contains:
> +@PluginAttribute(value = "blocking", defaultValue = "true")
> final boolean blocking,
>
Using a String default for a non-string attribute seems like a punch in the
eye ;-) This really feels unnatural.
Currently, I cannot say:
@PluginAttribute(value = "b
