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