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