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 <[email protected]> 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 <[email protected]> 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 <[email protected]>
>>>>>>> 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
>>>>>>> <[email protected]> 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
>>>>>>>>>> <[email protected]> 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 <[email protected]>
>>>>>>>>>>> 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
>>>>>>>>>>>>>> <[email protected]> wrote:
>>>>>>>>>>>>>> On Fri, Aug 16, 2013 at 2:28 PM, Scott Deboy
>>>>>>>>>>>>>> <[email protected]> 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 <[email protected]> wrote:
>>>>>>>>>>>>>>> On Fri, Aug 16, 2013 at 1:13 PM, Ralph Goers
>>>>>>>>>>>>>>> <[email protected]>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
>>>>>>>>>>>>>>>>> <[email protected]> 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
>>>>>>>>>>>>>>>>> <[email protected]>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
>>>>>>>>>>>>>>>>> <[email protected]>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, [email protected] wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Modified:
>>>>>>>>>>>>>>>>> logging/log4j/log4j2/trunk/core/src/test/resources/log4j2-config.xml
>>>>>>>>>>>>>>>>>> URL:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> 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
>>>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
