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]
