a) LOG4J2-170 reports that the xsd isn't current for the latest releases of Log4j. b) Obviously, anyone using the xsd to enforce the validity of their XML is going to be restricted to what the xsd allows. c) I believe the xsd follows the "strict" syntax. Our documentation typically doesn't use that.
Ralph On May 8, 2013, at 1:01 PM, Gary Gregory wrote: > 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 >> 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
