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. >>>>>>> >>>>>>> The technical side of parsing a flat properties map into a tree of >>>>>>> Nodes isn't that difficult. I'm sure we all took data structures at some >>>>>>> point in our lives ;) >>>>>>> >>>>>>> Due to the limitations of properties files, the format has to be >>>>>>> slightly different than the usual hierarchy used in all the other >>>>>>> formats. >>>>>>> The key difference I'd say is that instead of the "name" attribute used >>>>>>> on >>>>>>> all the appenders and loggers, the name would be the child "node" of the >>>>>>> appenders element. For instance: >>>>>>> >>>>>>> appenders.Name.attribute = ... >>>>>>> appenders.Name.anotherAttribute = ... >>>>>>> >>>>>>> Of course, the keys would be converted to lower case for case >>>>>>> insensitivity (which makes me think we could really use a >>>>>>> CaseInsensitiveHashMap or something). >>>>>>> >>>>>>> The old format uses something more like: >>>>>>> >>>>>>> log4j.appender.Name.attribute = ... >>>>>>> >>>>>>> For consistency, I think this should be appenders, and we could use >>>>>>> "log4j2" as the prefix (or even "configuration" for ultimate >>>>>>> consistency). >>>>>>> Thoughts? >>>>>>> >>>>>>> -- >>>>>>> Matt Sicker <[email protected]> >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Matt Sicker <[email protected]> >>>>> >>>> >>>> >>> >>> >>> -- >>> Matt Sicker <[email protected]> >>> >> >> >> >> -- >> Matt Sicker <[email protected]> >> > > > > -- > Matt Sicker <[email protected]> > > > -- Matt Sicker <[email protected]>
