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 16:43:40 GMT
Most of our configuration would be rudimentary, from doing a sampling of
the various config files I can just see many many instances of customized
levels for loggers with quite simplistic file appenders / rolling appenders
/ Console appender.

What I really want to do is utilize the LMAX Disruptor for logging in an
async / more performance optimized fashion compared to what we have now
using <version>1.2.17</version> ( head release )

I did see there is some level of support for it before the transition to
2.X began. Would it be worth my while using the Disruptor with .17 ?

While also investigating some sort of precedence based parsing approach;
parse and adapt the log4j XML config file if provided , override any
modifications made there with settings applied in a log4j2.xml file.



On 7 March 2016 at 16:34, Ralph Goers <ralph.goers@dslextreme.com> wrote:

> From the get-go Log4j implemented a new plugin system to make it easier
> for users to add their own components. In addition, new components such as
> global filters and markers were added. Finally, since the internal
> architecture changed none of the existing Log4j 1.x appenders or layouts
> could be used as is. All of this together meant the way configuration was
> done had to change. Additionally, the way configuration is done in Log4j 2
> is far more flexible.
>
> Yes, if you are using a small set of components, like a console appender,
> file appender and rolling file appender, you could probably write something
> that would emit a workable Log4j 2 configuration from a log4j 1
> configuration.
>
> Ralph
>
>
> > On Mar 7, 2016, at 9:10 AM, Daniel Walsh <walshd11@tcd.ie> wrote:
> >
> > 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 <pbenedict@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.goers@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 <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>
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>>
> >>>
> >>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>

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