If we support .properties, what is going to be the story for 1.2 users? The first question will likely be: why can't I use my 1.2 .properties file with 2.0. Even if we do not support 1.2 files, we need to document how to port I would think.
Gary On Mon, Jun 9, 2014 at 9:46 AM, Paul Benedict <[email protected]> wrote: > I remember a ticket (dunno which one) being closed out as "Won't Fix" for > the properties format. Are you gong to reopen it since you're working on > the feature? > > > Cheers, > Paul > > > On Mon, Jun 9, 2014 at 8:43 AM, Matt Sicker <[email protected]> wrote: > >> >> >> On Sunday, 8 June 2014, Remko Popma <[email protected]> wrote: >> >>> With xml, you'd wrap all <property ...> tags in a <properties> >>> encapsulating list element, but perhaps that is not needed in this format? >>> >>> So, instead of: >>> log4j2.properties.property.key=value >>> we could have: >>> log4j2.property.key=value >>> >>> I like it. >> >> >>> Also (and this is just a matter of taste), can we use "appender" and >>> "logger" instead of the plural "appenders"/"loggers"? >>> >>> Also would prefer that. Both would require hard coded plugins instead of >> generic lookups, though. Unless maybe we added @PluginAliases for them :) >> >> >>> What would the config for a root logger look like? >>> >>> That one is already implicit in the code. If you configure a logger >> named "root", that's changed to "" and treated as the root logger. Probably >> deserves some documentation, though. >> >> >>> One more thing: do we still need the .name attribute? >>> This seems a bit redundant: >>> log4j2.appender.File.name=File >>> Perhaps better to remove it so we won't have to deal with cases like >>> this: >>> log4j2.appender.File.name=NotFile >>> >>> >>> >>> Sent from my iPhone >>> >> No, I guess not. But it could be optional because logger configs have >> long names. >> >> >>> >>> On 2014/06/09, at 8:02, Matt Sicker <[email protected]> wrote: >>> >>> I was thinking about that. It would make sense. >>> >>> I'm trying to figure out how to do this generically so that special >>> cases don't need to be created. This file format is very limited, that's >>> for sure. >>> >>> >>> On 8 June 2014 17:10, Ralph Goers <[email protected]> wrote: >>> >>> One thing you could do is remove the type attribute by doing: >>> >>> log4j2.appenders.STDOUT=Console >>> >>> Ralph >>> >>> >>> On Jun 8, 2014, at 1:57 PM, Matt Sicker <[email protected]> wrote: >>> >>> https://paste.apache.org/e4m6 >>> >>> Damn quick fingers. >>> >>> >>> On 8 June 2014 15:57, Matt Sicker <[email protected]> wrote: >>> >>> Actually, what I'm trying to do first is convert the log4j-test1 file >>> into a properties file before going anywhere with this. Basically, it'll >>> have to be more like the XML strict format. Here's how I've converted it >>> (as you can see, this file format sucks): >>> >>> >>> >>> On 8 June 2014 15:20, Matt Sicker <[email protected]> wrote: >>> >>> So far it's awkward, but so was the original format. >>> >>> >>> On 8 June 2014 15:07, Paul Benedict <[email protected]> wrote: >>> >>> Ooops. Yes, XSL. The use of the XSL is to show that it's really possible >>> to convert an XML file into a flat file that's useable. >>> >>> >>> Cheers, >>> Paul >>> >>> >>> On Sun, Jun 8, 2014 at 2:40 PM, Matt Sicker <[email protected]> wrote: >>> >>> Of course XML is the better format. Like I said, I don't even use the >>> properties file format. However, plenty of people still do, so it seems >>> beneficial to allow it in some form. >>> >>> Do you mean an XSL file? >>> >>> >>> On 8 June 2014 14:21, Paul Benedict <[email protected]> wrote: >>> >>> I still think XML is a better format. But if you do allow property >>> files, consider first an XSD file that converts XML to properties. Because >>> if you can accomplish that, you will have proven to yourself that the >>> property file can represent everything an XML file can. >>> On Jun 8, 2014 2:00 PM, "Matt Sicker" <[email protected]> wrote: >>> >>> I'm only working on this because it sounds interesting and has been >>> requested by several people. I personally never use this file format in >>> Log4j 1, so I'm not entirely sure on how to best maintain compatibility or >>> similarity to the old format. >>> >>> >> >> -- >> Matt Sicker <[email protected]> >> > > -- E-Mail: [email protected] | [email protected] 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
