[
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)
