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. >>>>>> >>>>>> 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 <boa...@gmail.com> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Matt Sicker <boa...@gmail.com> >>>> >>> >>> >> >> >> -- >> Matt Sicker <boa...@gmail.com> >> > > > > -- > Matt Sicker <boa...@gmail.com> > -- Matt Sicker <boa...@gmail.com>
