Was there a discussion at the outset of 2.X as to abandon support for the pre-existing ( if laboriously heavy ) configuration files as they stood ?
A cost / benefit analysis ? It was obviously considered a blocking point to design backwards compatibility modules for the re-factored codeline moving under org.apache.logging.log4j I imagine anywhere where detail has been omitted in the new versions I can skip provided data in my Parser ( which at this point would be more a Transformer as you mentioned its other requirements ) Additionally I expect it wouldn't be an insurmountable challenge to provide sane defaults where details are lacking from the config files I'd be reading. On 7 March 2016 at 16:07, Paul Benedict <pbened...@apache.org> wrote: > Ditto. Ralph is right. It's not really about the format but the different > classes and options. > > Cheers, > Paul > > On Mon, Mar 7, 2016 at 10:04 AM, Ralph Goers <ralph.go...@dslextreme.com> > wrote: > > > I suspect it isn’t quite as simple as that. Many of the appenders use > > different parameters, class names aren’t specified any more, and the way > > parameters are specified is different. > > > > Ralph > > > > > On Mar 7, 2016, at 8:52 AM, Matt Sicker <boa...@gmail.com> wrote: > > > > > > There is no current support for the previous format, but the docs do > give > > > examples on how to convert to the new format: > > > > > > http://logging.apache.org/log4j/2.x/manual/migration.html > > > > > > Patches are always welcome to add support for the old config format, > but > > > it's non-trivial. The new formats are very similar to the old, so it's > > > probably not too hard. I bet an XSLT could be made to convert the XML > > > format automatically for most use-cases. > > > > > > On 7 March 2016 at 09:42, Daniel Walsh <walsh...@tcd.ie> wrote: > > > > > >> Hi Log4j Usergroup, > > >> > > >> I have a question regarding support for the previous 1.x configuration > > >> files. > > >> > > >> I wish to upgrade the version of Log4j across my companies platform, > > >> however when we deploy our software we expose public logger xml files > > for > > >> our clients to customize as they wish, this means that in any > > pre-existing > > >> installation we upgrade we need to be able to support their > personalized > > >> configuration, generally any action that would mutate a > > client-modifiable > > >> file is seen as a blocking issue , not to be attempted under any > > >> circumstance. > > >> > > >> I haven't seen any relevant documentation regarding support for the > > legacy > > >> configuration mode, even the 1.X adapter module looks as if it is > > intended > > >> as only a wrapper for the package name refactoring. > > >> > > >> Is support for the legacy configuration files currently possible using > > the > > >> latest release of Log4j2.x ? > > >> > > >> Thanks, > > >> Daniel > > >> > > > > > > > > > > > > -- > > > Matt Sicker <boa...@gmail.com> > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > > For additional commands, e-mail: log4j-user-h...@logging.apache.org > > > > >
