I do see the upside to how you do it, but at the same time annotating a method
parameter with BOTH annotations is going to get messy. Hmmm...
I'm not sure what I think. How important is being able to search for plugins
with aliases?
N
On Aug 17, 2013, at 10:45 AM, Ralph Goers wrote:
> This isn't quite what I did but I can certainly change it if you think what
> you have below is better. @Plugin and @PluginAttr are unchanged.
> @PluginAliases allows you to specify one or more aliases as
>
> @PluginAliases("appender-ref")
>
> or
>
> @PluginAliases({"appender-ref", "AppenderReference"})
>
> You add the PluginAliases annotation to the plugin class declaration and/or
> the plugin factory's parameter declaration.
>
> The advantage I see in this is that Plugins and attributes still only have
> one primary name and it is pretty easy to find plugins with aliases just by
> searching for uses of the annotation. With what you have below the first item
> in the array would have to be presumed to be the primary name.
>
> Ralph
>
>
> On Aug 17, 2013, at 7:57 AM, Nick Williams wrote:
>
>> Nope.
>>
>> - String name() in @Plugin (for element-mapped plugin classes) becomes
>> String[] names(). Annotation can be used @Plugin(names = "element") for
>> single-worders or @Plugin(names = { "elementName", "element-name" }) for
>> multi-worders.
>>
>> - String value() in @PluginAttr (for attribute-mapped method parameters)
>> becomes String[] value(). Keeping this singular is important for Java
>> language reasons. Annotation can be used @PluginAttr("attribute") for
>> single-worders or @Plugin({ "attributeName", "attribute-name" }) for
>> multi-worders.
>>
>> - String value() in @PluginElement (for attribute-mapped method parameters)
>> becomes String[] value(). Keeping this singular is important for Java
>> language reasons. Ditto on usage as $PluginAttr.
>>
>> Nick
>>
>> On Aug 17, 2013, at 9:49 AM, Gary Gregory wrote:
>>
>>> I am ok with an alias feature.
>>>
>>> Like this?
>>>
>>> @pluginElement(names="a, b, c")
>>>
>>> Gary
>>>
>>> On Aug 17, 2013, at 10:19, Ralph Goers <rgo...@apache.org> wrote:
>>>
>>>> So I think Remko and I agree that consistency is good but that there are
>>>> two cases where exceptions should be made. If I commit the change to
>>>> alias those two things is anyone so strongly against it that they would
>>>> veto it? If not then I would like to commit it.
>>>>
>>>> Ralph
>>>>
>>>> On Aug 17, 2013, at 12:45 AM, Remko Popma <remko.po...@gmail.com> wrote:
>>>>
>>>>> ApPeNdeRrEf may look visually as confusing as a-p-p-e-n-d-e-r-r-e-f
>>>>> r-e-f,
>>>>> but that is not the point.
>>>>>
>>>>> I think the rule "config files are case-insensite" is much a more
>>>>> intuitive rule than "all hyphens are stripped from attribute and element
>>>>> names".
>>>>>
>>>>> To me, the "-ref" extension in the <appender-ref> element is a nice,
>>>>> visually distinct indicator that this element points to another element
>>>>> in the configuration. To me, these pointer elements/attributes are
>>>>> special elements and attributes and we actually *lose* something if we
>>>>> bend over backwards to make them look consistent with other elements.
>>>>> It's okay if they look different because they *are* different.
>>>>>
>>>>> If we prefer not to have aliases then I propose we revert back the
>>>>> appender-ref and error-ref elements to the hyphen version. I think they
>>>>> are better names.
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Aug 17, 2013 at 3:48 PM, Gary Gregory <garydgreg...@gmail.com>
>>>>> wrote:
>>>>> Dancing angels and pin heads:
>>>>>
>>>>> Yep, the patch I provided allows for <a-p-p-e-n-d-e-r-r-e-f
>>>>> r-e-f="Console"/> but the point is that is allows <appender-ref
>>>>> ref="Console>
>>>>>
>>>>> But! the current code also allows <ApPeNdeRrEf ref="Console/>
>>>>>
>>>>> How is that any better/worse, more/less confusing?
>>>>>
>>>>> BTW, are attributes also case-insensitive? <ApPeNdeRrEf ReF="Console/>
>>>>>
>>>>> Gary
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Aug 17, 2013 at 2:38 AM, Ralph Goers <ralph.go...@dslextreme.com>
>>>>> wrote:
>>>>> OK. In general I guess I agree with your philosophy. However, I
>>>>> consider stripping/ignoring hyphens bad because then
>>>>> <a-p-p-e-n-d-e-r-r-e-f r-e-f="Console"/> becomes valid. The ONLY reason
>>>>> I wanted aliases is because I really believe users who are used to the
>>>>> "other" logging frameworks are constantly going to screw up and do
>>>>> <appender-ref ref="abc"/> instead of <AppenderRef ref="abc"/> simply
>>>>> because they are used to it. However, if my choice is between stripping
>>>>> or leaving it the way it is then I vote to leave it the way it is.
>>>>> Again, I just detest the idea of stripping hyphens.
>>>>>
>>>>> Ralph
>>>>>
>>>>> On Aug 16, 2013, at 11:28 PM, Nick Williams wrote:
>>>>>
>>>>>> Alright. Time to chime in I suppose, since I'm being quoted now. :-)
>>>>>>
>>>>>> I like consistency. I like the same rules to apply to all parts of the
>>>>>> configuration. For example:
>>>>>>
>>>>>> - If we decide that an element should be PascalCase, then they should
>>>>>> ALL be PascalCase.
>>>>>> - If we decide that an attribute should be camelCase, then they should
>>>>>> ALL be camelCase.
>>>>>> - If we decide that an element and/or attribute should be
>>>>>> case-insensitive, then ALL elements AND attributes should be
>>>>>> case-insensitive.
>>>>>> - If we decide that an element and/or attribute should allow hyphens
>>>>>> between words, then ALL elements AND attributes should allow hyphens
>>>>>> between words.
>>>>>>
>>>>>> This last one is a key point here. Providing aliases would not be a sane
>>>>>> way to do this, because what if a developer added an attribute but
>>>>>> forgot to create a hyphenated alias? Suddenly, all elements and
>>>>>> attributes would allow hyphenation—except that one attribute. This is a
>>>>>> consistency failure.
>>>>>>
>>>>>> I'm not arguing against aliases, necessarily. I just think they're a Bad
>>>>>> way to solve the hyphenation dispute (yes, capital Bad). With the
>>>>>> hyphenation issue solved otherwise (either by disallowing hyphens or by
>>>>>> stripping hyphens automatically), I no longer see a compelling need for
>>>>>> aliases. The addition of aliases also makes the task for users of
>>>>>> extending Log4j / writing plugins for Log4j more confusing.
>>>>>>
>>>>>> If I had to chose what we were going to do here, these are my
>>>>>> preferences/priorities, in order from most important to least important:
>>>>>>
>>>>>> - Consistency, consistency, consistency.
>>>>>> - A strict schema that must be validated against for the Log4j
>>>>>> configuration to work. No case insensitivity, no stripping of hyphens.
>>>>>> - All lowercase, hyphenated elements AND attributes. No PascalCase, no
>>>>>> camelCase.
>>>>>> - camelCase elements AND camelCase attributes.
>>>>>> - PascalCase elements AND PascalCase attributes.
>>>>>>
>>>>>> Nick
>>>>>>
>>>>>> On Aug 17, 2013, at 1:14 AM, Ralph Goers wrote:
>>>>>>
>>>>>>> On Aug 10 Nick said "I actually really like hyphenated attributes, but
>>>>>>> I like consistency better.". However, that doesn't imply that he is
>>>>>>> going to like allowing '-' to appear anywhere and be stripped out.
>>>>>>> Providing aliases would be a more sane way to do that.
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Aug 16, 2013, at 10:57 PM, Gary Gregory wrote:
>>>>>>>
>>>>>>>> On Sat, Aug 17, 2013 at 1:44 AM, Ralph Goers
>>>>>>>> <ralph.go...@dslextreme.com> wrote:
>>>>>>>> So far yours is the only vote for that. Anyone else?
>>>>>>>>
>>>>>>>> Whomever else mentioned it in the first place! ;) I can't recall
>>>>>>>> who... but it's 2am here...
>>>>>>>> G
>>>>>>>>
>>>>>>>> Ralph
>>>>>>>>
>>>>>>>> On Aug 16, 2013, at 10:19 PM, Gary Gregory wrote:
>>>>>>>>
>>>>>>>>> I think we should do both.
>>>>>>>>>
>>>>>>>>> Gary
>>>>>>>>>
>>>>>>>>> On Aug 16, 2013, at 21:59, Ralph Goers <ralph.go...@dslextreme.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Easily done, assuming we have consensus. I am hearing two options:
>>>>>>>>>> 1) strip '-' characters from element names.
>>>>>>>>>> 2) allow aliases for element names.
>>>>>>>>>>
>>>>>>>>>> These are not mutually exclusive. I see no reason not to go ahead
>>>>>>>>>> with number 2 and we can continue to discuss where else number 1
>>>>>>>>>> might be used.
>>>>>>>>>>
>>>>>>>>>> Ralph
>>>>>>>>>>
>>>>>>>>>> On Aug 16, 2013, at 2:21 PM, Remko Popma wrote:
>>>>>>>>>>
>>>>>>>>>>> Ralph,
>>>>>>>>>>> Don't forget the error-ref attribute for AsyncAppender.
>>>>>>>>>>>
>>>>>>>>>>> Remko
>>>>>>>>>>>
>>>>>>>>>>> On Saturday, August 17, 2013, Ralph Goers wrote:
>>>>>>>>>>> I'm not in favor of just allowing arbitrary '-' characters wherever
>>>>>>>>>>> users want. But allowing aliases makes it possible to allow for
>>>>>>>>>>> variations. I already have this working.
>>>>>>>>>>>
>>>>>>>>>>> Ralph
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Aug 16, 2013, at 11:39 AM, Gary Gregory wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Aug 16, 2013 at 2:38 PM, Gary Gregory
>>>>>>>>>>>> <garydgreg...@gmail.com> wrote:
>>>>>>>>>>>> On Fri, Aug 16, 2013 at 2:28 PM, Scott Deboy
>>>>>>>>>>>> <scott.de...@gmail.com> wrote:
>>>>>>>>>>>> I'm not sure if this ship has fully sailed, but I'd prefer to see
>>>>>>>>>>>> us
>>>>>>>>>>>> stick with he dash format due to folks being familiar with it from
>>>>>>>>>>>> log4j 1.
>>>>>>>>>>>>
>>>>>>>>>>>> That's a thin argument IMO considering you'll have to read the
>>>>>>>>>>>> version 2 config docs to get off the ground anyway, even if you
>>>>>>>>>>>> know your way around version 1.
>>>>>>>>>>>>
>>>>>>>>>>>> And this is also an opportunity to make our config code even
>>>>>>>>>>>> fancier by normalizing '-' chars ;)
>>>>>>>>>>>>
>>>>>>>>>>>> Gary
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Gary
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Scott
>>>>>>>>>>>>
>>>>>>>>>>>> On 8/16/13, Gary Gregory <garydgreg...@gmail.com> wrote:
>>>>>>>>>>>>> On Fri, Aug 16, 2013 at 1:13 PM, Ralph Goers
>>>>>>>>>>>>> <ralph.go...@dslextreme.com>wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm adding an aliases attribute to the Plugin annotation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hold on to your horses ;)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Another way to look at this is that our config parsing that is
>>>>>>>>>>>>> already
>>>>>>>>>>>>> case-insensitive could be augmented to strip out "-"s, no aliases
>>>>>>>>>>>>> needed.
>>>>>>>>>>>>>
>>>>>>>>>>>>> As someone pointed out here, some folks like-to-talk-like-this
>>>>>>>>>>>>> (see JPA).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Gary
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Aug 16, 2013, at 6:38 AM, Remko Popma wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Maybe we just need another plugin for the 2nd name then.
>>>>>>>>>>>>>> Subclass or
>>>>>>>>>>>>>> delegate?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Friday, August 16, 2013, Ralph Goers wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I had the same thought. People switching from log4j 1 or
>>>>>>>>>>>>>>> logback will
>>>>>>>>>>>>>>> probably make that mistake a lot. Plus this breaks virtually
>>>>>>>>>>>>>>> everyone
>>>>>>>>>>>>>>> currently using Log4j 2. The problem is that I don't think
>>>>>>>>>>>>>>> there is
>>>>>>>>>>>>>>> currently a way for a plugin to have 2 names.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Sent from my iPad
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Aug 16, 2013, at 6:03 AM, Remko Popma
>>>>>>>>>>>>>>> <remko.po...@gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Would it be an idea to support both appender-ref and appenderRef
>>>>>>>>>>>>>>> attributes?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Thu, Aug 15, 2013 at 10:22 AM, Gary Gregory
>>>>>>>>>>>>>>> <garydgreg...@gmail.com>wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I never thought that Log4J 2 configuration files should be
>>>>>>>>>>>>>>> backward
>>>>>>>>>>>>>>> compatible with version 1, and even less so with a different
>>>>>>>>>>>>>>> product.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Gary
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Wed, Aug 14, 2013 at 8:51 PM, Ralph Goers
>>>>>>>>>>>>>>> <ralph.go...@dslextreme.com>wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Now that I see this it kind of scares me. Log4j 1.x and
>>>>>>>>>>>>>>> Logback both
>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>> appender-ref. Anyone using Log4j 2 will now be broken.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Aug 14, 2013, at 1:05 PM, ggreg...@apache.org wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Modified:
>>>>>>>>>>>>>>> logging/log4j/log4j2/trunk/core/src/test/resources/log4j2-config.xml
>>>>>>>>>>>>>>>> URL:
>>>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@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
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@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
>>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
