We shouldn't close feature requests as won't fix. Someone may come along later and decide to implement it.
It's ok to say no one is planning on working on the feature, and remind the submitter that patches are welcome. Scott Scott On Jun 9, 2014 6:46 AM, "Paul Benedict" <pbened...@apache.org> 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 <boa...@gmail.com> wrote: > >> >> >> On Sunday, 8 June 2014, Remko Popma <remko.po...@gmail.com> 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 <boa...@gmail.com> 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 <ralph.go...@dslextreme.com> 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 <boa...@gmail.com> wrote: >>> >>> https://paste.apache.org/e4m6 >>> >>> Damn quick fingers. >>> >>> >>> On 8 June 2014 15:57, Matt Sicker <boa...@gmail.com> 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 <boa...@gmail.com> wrote: >>> >>> So far it's awkward, but so was the original format. >>> >>> >>> On 8 June 2014 15:07, Paul Benedict <pbened...@apache.org> 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 <boa...@gmail.com> 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 <pbened...@apache.org> 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" <boa...@gmail.com> 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 <boa...@gmail.com> >> > >
