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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
