The XML Schema we have defined does not allow this kind of flexibility. To define such a schema would be quite complicated and not something I want to see.
I want an XML Schema I can (1) use for validation and (2) use with editors that are schema aware (content assist and all). Right now, we have the worst of both worlds: An XML Schema that is supposed to tell me what is allowed but does not fully AND I need to know special rules about casing, nesting and so on. Imaging writing a Log4j configuration file editor (that lives in a larger tool suite) and you'll see the pain the current system gives. I have to be able to read any old Log4j configuration file, edit it and write it back out. On Wed, May 8, 2013 at 3:31 PM, Nick Williams <nicho...@nicholaswilliams.net > wrote: > Is this a matter of examples, or are the elements actually case sensitive > (i.e., will BOTH <console></console> AND <Console></Console> work)? > I recall someone saying that the XML processing in Log4j is not case sensitive, which is not a good thing IMO. How do write an XML Schema for that?! > If it's a matter of examples, then lets make all of the elements > consistent in examples. > > If the elements are actually case sensitive and <console></console> won't > work, my arguments are (in order of importance): > > 1) No matter what, be consistent. All element names should use the same > casing as all other element names, all attribute names should use the same > casing as other attribute names. > > 2) The Log4j 2 configuration was designed to be rather forgiving (e.g., > attributes can be specified as sub-elements instead). I think all matches > should be performed case-insensitively, just like HTML, if we want to > further the goal of forgiveness. There's no reason for two appenders to > have the same name with a different case, for example, so there's no risk > of collision. > Like HTML? And look the mess HTML is, should we also allow quotes on attribute values to be omitted like some HTML elements? That would be 'flexible', ahem. We are beyond the days of hand-tinkering with configuration files. I'm not sure why we want to maintain an additional level of complexity with this kind of XML processing. > > 3) My preference is for element names to always be a single word that's > all lower case, > That's living on fantasy island ;) We already have multi-word elements: PatternLayout, ThreadContextMapFilter, and the ugly (IMO) appender-ref. So in fact, there are are THREE styles, not two! ElementName, elementName and element-name. Yikes, I do not like that at all. I see XML elements like classes and XML attributes like instance variables; which is how JAXB generates code BTW. In my tools, I want an XML Schema I can use to generate JAXB code and use that to author config files from our tools. Right now, our schema does not even define the Core appenders, so it's lacking too. Ideally, Log4J2 would generate JAXB code as part of the build. Whether or not this JAXB code should be used by Log4j itelf is another debate. I suppose the XSD could be generated based on scanning the code for plugins too, but that's beyond this thread. I'd be happy with a schema that tells me all that log4j can do out of the box. Gary > and for attribute names to be camelCase. > > Nick > > > On May 8, 2013, at 2:20 PM, Gary Gregory wrote: > > Our XML looks messy ATM because we mix two styles of XML element names: > ElementName and elementName. For example *appenders* and *Console*. I > propose we use ElementName throughout. Attribute usage is consistent with > attributeName. > > Current messy example from > https://svn.apache.org/repos/asf/logging/log4j/log4j2/trunk/core/src/test/resources/log4j-filetest.xml > > <configuration status="debug" dest="target/status.log" > name="XMLConfigTest" packages="org.apache.logging.log4j.test"> > <properties> > <property name="filename">target/test.log</property> > </properties> > <ThresholdFilter level="debug"/> > > <*appenders*> > <*Console *name="STDOUT"> > <PatternLayout pattern="%m%n"/> > </Console> > <File name="File" fileName="${filename}" bufferedIO="false"> > <PatternLayout> > <pattern>%d %p %C{1.} [%t] %m%n</pattern> > </PatternLayout> > </File> > <List name="List"> > <filters> > <ThresholdFilter level="error"/> > </filters> > </List> > </appenders> > > <loggers> > <logger name="org.apache.logging.log4j.test1" level="debug" > additivity="false"> > <ThreadContextMapFilter> > <KeyValuePair key="test" value="123"/> > </ThreadContextMapFilter> > <appender-ref ref="STDOUT"/> > </logger>> > > <logger name="org.apache.logging.log4j.test2" level="debug" > additivity="false"> > <appender-ref ref="File"/> > </logger>> > > <root level="error"> > <appender-ref ref="STDOUT"/> > </root> > </loggers> > > </configuration> > > Thoughts? > > Gary > -- > 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
