I've not received any comments on this patch. I plan to commit it tomorrow.

Ralph

On Aug 17, 2013, at 9:01 AM, Ralph Goers wrote:

> I've added it to LOG4J2-360.
> 
> Ralph
> 
> On Aug 17, 2013, at 8:59 AM, Ralph Goers wrote:
> 
>> I will just upload what I currently have as a patch to the Jira issue and 
>> then you can take a look.  I don't think it is all that messy myself.
>> 
>> Ralph
>> 
>> On Aug 17, 2013, at 8:52 AM, Nick Williams wrote:
>> 
>>> 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
>>> 
>> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Reply via email to