[jira] [Commented] (OFBIZ-5287) Migrating from Log4j 1.2.17 to log4j2

["Jacopo Cappellato (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OFBIZ-5287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14100524#comment-14100524 ] 

Jacopo Cappellato commented on OFBIZ-5287:
------------------------------------------

I have successfully completed the work to upgrade OFBiz to Log4j2.
I am happy about the result: after the upgrade we have less code dependent on internal Log4j api, the Log4j2 is much faster and I have rewritten the configuration files to follow the guidelines for performance.
If you agree, I would like to commit my work and then wait for community review; there are some decisions I have taken (especially in the formatting of log messages and in the rotation and naming of files) that we could review and refine together over time. If not, I will attach a patch to the ticket OFBIZ-5287 and give you a chance to review before I commit.

Here are the main points to consider:

* programmatically changing the configuration of Log4j2 is now discouraged and so I have removed all the code that we had to update and add new appenders and to set their logging levels; however I have enabled a new feature that tells Log4j2 to read the configuration file every x seconds (I have set it to 60 seconds) and apply any changes made to them at runtime; with this we will have a change to modify appenders, loggers and everything else while OFBiz is running; so it is now more flexible (without the need to maintain custom code) but we can't do this from webtools as we did before (but we could always implement a screen in webtools to edit the logfj2.xml file)
* I have removed the custom "notify" level (and the corresponding Debug.logNotify(...) methods) that was not used in OFBiz and required some old API to work
* I had to disable the logging in the POS component because it was using the old API; in my opinion we should use the standard log4j2 logging instead of the custom methods but I didn't work on it pending a discussion with the community to better understand the requirements
* I have removed the pack.exception setting because it required a (pretty old) Avalon jar and because it seemed a rather irrelevant feature (that adds load to runtime processing); but this change was not really required and I can bring it back easily if there are concerns
* I have removed the information about the Java class and line from the log statements (they are still there for Minilang, and the Java module is still there of course); I did it because it required significant resources and was very slow (i.e. it required the creation and parsing of a thread dump); I did it accordingly to the following recommendations (http://logging.apache.org/log4j/2.x/manual/layouts.html#LocationInformation ):
{quote}If one of the layouts is configured with a location-related attribute like HTML locationInfo, or one of the patterns %C or $class, %F or %file, %l or %location, %L or %line, %M or %method, Log4j will take a snapshot of the stack, and walk the stack trace to find the location information.

This is an expensive operation: 1.3 - 5 times slower for synchronous loggers. Synchronous loggers wait as long as possible before they take this stack snapshot. If no location is required, the snapshot will never be taken.

However, asynchronous loggers need to make this decision before passing the log message to another thread; the location information will be lost after that point. The performance impact of taking a stack trace snapshot is even higher for asynchronous loggers: logging with location is 4 - 20 times slower than without location. For this reason, asynchronous loggers and asynchronous appenders do not include location information by default.{quote}

* I have also tried to format the logs in a more compact way and to maintain a fixed position for the information of each line to make them more readable; we can refine this over time

* I have unified some of the file appenders (i.e. freemarker.log, fop.log, tomcat.log); now we have ofbiz.log for all the logging statements from OFBiz (same as before) and external.log from logging coming from external jars; again we can refine this based on feedback from the community


> Migrating from Log4j 1.2.17 to log4j2
> -------------------------------------
>
>                 Key: OFBIZ-5287
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-5287
>             Project: OFBiz
>          Issue Type: Improvement
>          Components: framework
>    Affects Versions: Trunk
>            Reporter: Jacques Le Roux
>            Assignee: Jacopo Cappellato
>            Priority: Minor
>
> Mostly because of the introduction of  [LMAX Disruptor library|http://martinfowler.com/articles/lmax.html] in log4j 2, but not only, I want to upgrade log4j to [log4j 2|http://logging.apache.org/log4j/2.x/]
> [The migration does not seem too hard to do| http://logging.apache.org/log4j/2.x/manual/migration.html]. I found only usage of Appender when unloading containers and of course in 
> Debug.java; Appender  and LoggerRepository  classes
> There is also [a easy to install bridge for SLF4J|https://loggapache.org/log4j/2.x/log4j-slf4j-impl/index.html]
> About LMAX Disruptor, [here is a brief introduction|http://stackoverflow.com/questions/6559308/how-does-lmaxs-disruptor-pattern-work], 
> I discovered the usage of LMAX Disruptor in log4j2 [through this blog entry|http://www.grobmeier.de/log4j-2-performance-close-to-insane-20072013.html#.UepjvGTfxFo]



--
This message was sent by Atlassian JIRA
(v6.2#6252)