Hi
We have been looking into $subject and these are the findings we have
arrived at so far.
Carbon 4.x.x currently uses Log4J 1.x as the logging back-end and following
will have to be done when migrating to Log4J 2.x.
1. Rewriting custom appenders
- Current Log4J 1.x method - Rewriting of Logging Events by extending
appropriate classes (i.e.:
AppenderSkeleton/ConsoleAppender/DailyRollingFileAppender)
[1]
- Proposed Log4J 2.x method - Use of plugins to convert the log
record into a required pattern with custom fields [2]
2. Replace log4j.properties with a log4j2.properties file
- The properties file should be changed to log4j2.properties and the
syntax will different from v1 format [3]
3. Remove
- Direct use of log4j in org.wso2.carbon.server.Main - used to remove
all appenders added in the non-OSGi environment
- Package org.wso2.carbon.utils.logging.appenders as this should be
rewritten as converter plugins
The following approaches were found and evaluated to identify the most
suitable one.
1. Using pax-logging
- The pax-logging api and the pax-logging-log4j bridge will have to be
used.
- Supposedly, pax-logging will feed the front-end logging into its
log4j back-end using its built-in adapter which we are trying to
achieve at the moment
2. Using Log4J 2.x
- This will need the log4j2-core, log4j2-api and the bridges to map
the front-end logging api to Log4J 2.x back-end
- Also this needs two OSGi fragments to customize the log4j-core and
log4j-api work in OSGi
- This requires the log4j2.properties file to be in the fragment used
with log4j-core and therefore, the file cannot be edited later
- Also, external .jar files are not able to find the logging
implementation which we are still investigating as to why this happens
3. Using both Log4j 1.x and 2.x
- While C4 will use the latter as the back-end, the external jars
needing v1 will use the former
- This could lead to threading issues since appenders from two log4J
versions will write to a single file simultaneously
4. Using the Log4J 1.x bridge [4]
- The Log4J 1.x jar is replaced with the 1.x bridge api and the
required log4j2 files. This will redirect all the logs from
Log4j 1.x to 2.x
- This only works if there are no custom appenders
As per the current state, first approach will need the least changes and
since pax-logging is OSGi compatible this seems to be suitable. However,
the 2nd approach is also being looked into to fix the aforementioned
drawbacks and issues.
Thoughts please
[1] https://logging.apache.org/log4j/1.2/apidocs/org/apache/
log4j/spi/LoggingEvent.html
[2] http://logging.apache.org/log4j/2.x/manual/plugins.html
[3] https://logging.apache.org/log4j/2.0/manual/configuratio
n.html#Properties
[4] https://logging.apache.org/log4j/2.x/manual/migration.html
--
Asma Zinneera Jabir
Software Engineer
WSO2 Inc: http://wso2.com/
Contact No: +94 77 332 4752 <+94%2077%20332%204752>
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
