logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Walsh <walsh...@tcd.ie>
Subject Re: Log4j2 Backwards Compatibility
Date Mon, 07 Mar 2016 15:59:28 GMT
I would more than likely be forced to utilize a parser rather than an XSLT
to transform their pre-existing files.

Thanks for the info though. It'll be helpful when bringing the case for
upgrade. Its a pretty dramatic modification to our codeline if done, 100's
of poms owned by 10's of dev-teams / stakeholders with their own default
logging configurations, not to mention every client-site extension of their
default logging with further customizations.

I'll put the case to my higher ups, and if given the go ahead then I'll
have to invest in a way to interpret the pre-existing configuration.

If you have any suggestions on where to start / entry points into the
current configuration parser versus the 1.x one that would be appreciated.

Dan

On 7 March 2016 at 15:52, Matt Sicker <boards@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 <walshd11@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 <boards@gmail.com>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message