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: >>>> >>> >>>> <http://svn.apache.org/viewvc/logging/log4j/log4j2/trunk/core/src/test/resources/log4j2-config.xml?rev=1514021&r1=1514020&r2=1514021&view=diff> >>>> >>>> >>> >>> >> >> >> -- >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >> Java Persistence with Hibernate, Second >> Edition<http://www.manning.com/bauer3/> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >> Spring Batch in Action <http://www.manning.com/templier/> >> 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<http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory >
