On May 8, 2013, at 21:53, Remko Popma <rem...@yahoo.com> wrote: I don't have a strong opinion about this. I kind of like the way it is now, including case-insensitivity, and didn't really notice any messiness. I also liked that I didn't need to put a DOCTYPE...
Nick raised a good point about the custom plugins. If we create a tool to generate schema fragments during the build I would like to make sure that such a tool would work outside of Maven too. I didn't understand Gary's point about being beyond the days of hand-tinkering with configuration files. Doesn't everybody manually create and edit their log4j config file? Of course not. For example, at work, in our toolset for our runtime, our users never hand edit anything. We have a nice Eclipse-based GUI than configures a lot of different kinds of files, including Log4j. Then, our consultants may get in the loop at a customer site, and as advanced users, they may tinker with all the config files by hand and using the tools. Most of our end users are not programmers, so asking them to edit XML is asking for trouble, but asking them to click around a GUI to get our software in debug mode and send us a log file is fine. Gary Users probably start by copying one of the examples from the site and they go from there. I believe this (plain text editors) are the main use case and as long as we don't make this harder to understand or harder to use then I don't mind. Sent from my iPhone On 2013/05/09, at 6:29, Nick Williams <nicho...@nicholaswilliams.net> wrote: I wasn't even aware there WAS an XSD. I just found it. Some thoughts about this: 1) I know a DTD isn't as flexible as an XSD (and it's darn harder to write), but could this be accomplished with a DTD instead? If so, case insensitivity could then be enabled. DTDs can still be validated and still be used in editors for content assist. Might be a better course of action. 2) No matter how the schema is defined, the two obvious problems are A) updating it when a plugin changes and B) accounting for custom (user-supplied) plugins. A) Could be achieved through automation (e.g., it could be generated during the build process) ... boy, wouldn't that be fun to tackle? B) Cannot be achieved easily. I think the end-user (supplier of custom plugin) could create their own schema and add an additional xmlns to the document (or similar for DTD). The schema needs to be defined so that this is allowed, and elements of other namespaces can be placed inside elements (if that's possible). The existence of a schema for validation/editing definitely throws a wrench in things. Generally, XML-based configurations tend to be intentionally completely unforgiving when a schema is supplied (e.g., Spring Framework XML config). Nick On May 8, 2013, at 3:13 PM, Ralph Goers wrote: 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<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
