Hi Asma, > > 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 > > IMHO all these approaches also have a common issue. When we try to use any of those APIs we have to have to change our code base again and again according to the API we are using.
IMO what we should do is write our own API for Logging and in the implementation, we can use any of those as the backend. So only the implementation will be changed while our code base remains same. Please find the diagram below. [image: Inline image 1] WDYT? Thanks and best regards, Irunika *Irunika Weeraratne* *Software Engineer | WSO2, Inc. <http://wso2.com/>* *Email : irun...@wso2.com <irun...@wso2.com>* *LinkedIn : https://lk.linkedin.com/in/irunika <https://lk.linkedin.com/in/irunika>* *Mobile : +94712403314* *Lean . Enterprise . Middleware* On Wed, Jul 12, 2017 at 7:53 PM, Asma Jabir <as...@wso2.com> wrote: > 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 Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
