Alright, based on some introductory code, this is way too hard to accomplish before 2.0. It might be something worth looking at for 2.1.
On 9 June 2014 16:38, Matt Sicker <[email protected]> wrote: > You can, but the programmatic API ends up becoming a builder as it is. I > think it helps simplify code this way. > > > On 9 June 2014 15:15, Ralph Goers <[email protected]> wrote: > >> Why? Are you saying a programmatic API can’t call factory methods? I know >> that isn’t true. >> >> Ralph >> >> On Jun 9, 2014, at 12:40 PM, Matt Sicker <[email protected]> wrote: >> >> A groovy configuration would be rather groovy. That would be part of a >> programmatic configuration API, and that itself I think is dependent on >> using builders instead of factory methods for plugins. >> >> >> On 9 June 2014 11:22, Ralph Goers <[email protected]> wrote: >> >>> In this case it is won't fix because it just isn't possible to process >>> 1.2 configurations in 2.0. The components take different attributes and the >>> plugin system eliminates specifying classes. >>> >>> Sent from my iPhone >>> >>> On Jun 9, 2014, at 8:30 AM, Scott Deboy <[email protected]> wrote: >>> >>> 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" <[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 <http://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 <http://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]> >>>>> >>>> >>>> >> >> >> -- >> Matt Sicker <[email protected]> >> >> >> > > > -- > Matt Sicker <[email protected]> > -- Matt Sicker <[email protected]>
