Hi

Proceeding with the aforementioned, we replaced carbon-logging with
pax-logging. Now it is essential to start logging bundles before other
bundles and according to the current architecture the bundles are loaded as
per the bundles.info file which are listed in alphabetical order. Hence pax
logging bundle (org.ops4j.pax.logging*) is activated before carbon
components (org.wso2.carbon*). Since we have the naming convention to start
as org.wso2 pax-logging will always load prior to these components which
satisfies the necessity. Therefore, we did not try to load pax-logging
bundles forcefully as initial bundles like in c5.

Thoughts on this please.


Also, going forth we ran into an issue in the last bit of log messages
which are supposed to log after the OSGi framework is stopped. Below is the
final lines of code executed when the server shuts down.

log.info("Shutting down OSGi framework...");
EclipseStarter.shutdown();
log.info("Shutdown complete");
log.info("Halting JVM");
if (!isShutdownTriggeredByShutdownHook) {
    System.exit(0);
}

When the server shutdown is triggered, after the osgi framework is
shut down, the log messages that follow does not take the logging
configuration we provide with since pax-logging bundle is stopped when
OSGi is shutdown and hence takes a different pattern plus does not
write to the log files. At the moment we are looking into a solution
for this and any suggestions on solving this is appreciated.

Thank you

Regards,
Asma

On Fri, Aug 4, 2017 at 11:31 AM, Asma Jabir <as...@wso2.com> wrote:

> Hi all
>
> The following were finalized after the meeting [1] and the logging
> framework for C4 will be as follows.
>
>
> [image: Inline image 2]
>
> As shown above :
>
>    1. pax-logging-api will replace the org.wso2.carbon.logging and 
> org.wso2.carbon.logging
>    becomes obsolete from now on
>       - org.wso2.carbon logging is used by lot of other components and
>       therefore removing this entirely from the kernel will not allow to build
>       the product unless the maven dependency is removed from the pom of those
>       individual components
>       - Hence, org.wso2.carbon.logging will* not* be packed with the
>       kernel and at the runtime pax-logging-api will be providing the packages
>       required for logging
>    2. *org.ops4j.pax.logging.pax-logging-log4j2.jar* will bridge the logs
>    to log4J2 and write to console and log files
>    3. The custom appenders will be residing in a fragment of
>    *org.ops4j.pax.logging.pax-logging-log4j2.jar*
>    4. The *log4j.properties* file will be replaced by* log4j2.properties*
>       - The file will have to be converted to the new format manually
>    5. pax-logging.properties file will be used to point to the log4j2
>    configuration file (log4j2.properties)
>       - This will be set as a system property in *wso2server.sh* file
>       - Additionally, to get rid of unnecessary pax-logging messages,
>       another system property will be set to specify the logging level to WARN
>
> Therefore, the *following will be** removed* since they are no longer
> needed
>
>    - log4j and commons-logging packages exported in
>    org.wso2.carbon.logging
>       - Refer 1. above
>    - *$CARBON_HOME/repository/conf/log4j.properties file*
>    - *Refer 4 above*
>    - log4j.properties file packed inside *org.wso2.carbon.server*
>    - org.wso2.carbon.server will be changed to JUL and thus,
>       *$CARBON_HOME/repository/conf/etc/logging-bridge.properties* will
>       be the configuration file
>    - org.wso2.carbon.logging.propfile fragment bundle
>       - The configuration file (log4j2.properties) is used through
>       pax-logging.properties file which can be set as a system property
>    - org.wso2.carbon.utils.logging.LoggingUtils file and
>    org.wso2.carbon.utils.logging.appenders package
>    - Refer 3. above
>
> [1] [Discussion] C4 Migration from Log4J 1.x to Log4J 2.x @ Thu Aug 3,
> 2017 5pm - 6pm (IST)
>
> Thanks
>
> Regards,
> Asma
>
> On Wed, Aug 2, 2017 at 5:58 PM, Asma Jabir <as...@wso2.com> wrote:
>
>>
>> Hi Ruwan,
>>
>> As per the Log4J 2 documentation, CloseableThreadContext has to be used
>> in order to support this. This has to be inserted into the pipeline (before
>> reaching the kernel) similar to how the CarbonContext is created. The
>> explained scenario is valid but it relates more to usage of Log4J 2. At the
>> moment we are focusing on migration to Log4J 2 in C4 and therefore,
>> appreciate if you could raise this in jira so we can attend to it
>> separately.
>>
>> Thanks
>>
>> Regards,
>> Asma
>>
>> On Tue, Aug 1, 2017 at 5:56 PM, Ruwan Abeykoon <ruw...@wso2.com> wrote:
>>
>>> Hi Asma,
>>> Let me explain why we need NDC/MDC
>>>
>>> Lets say we are in Identity Server authentication flow. The call stack
>>> and the things pushed/popped in each method call will be different.
>>> e.g.
>>> 1. Request Received at Tomcat layer, [push {sessionId, correlationId}]
>>> 2. Request Dispatched to Authentication Framework [push
>>> {serviceProvider}]
>>> 3. Request is handling at an IdP [push {IdP_Name}]
>>> 4. Request is handling at authenticator [push {Authenticator Name}]
>>> 5. Request leaves at Idp [pop {IdPName}]
>>> 6. Request leaves at Authentication Framework [pop {serviceProvider}]
>>>
>>>
>>> So in effect any log line being printed at the each of the steps above
>>> prints something like the following.
>>> 1. -1234, [DEBUG], {sessionId=xyz, correlationId=null} , Something
>>> happened at Tomcat Layer
>>> 2. -1234, [DEBUG], {sessionId=xyz, correlationId=null,
>>> serviceProvider=App1} , Something happened at Framework Layer
>>> 3. -1234, [DEBUG], {sessionId=xyz, correlationId=null,
>>> serviceProvider=App1, IdP=MyIdP1} , Something happened at IdP Layer
>>> 4. -1234, [DEBUG], {sessionId=xyz, correlationId=null,
>>> serviceProvider=App1, IdP=MyIdP1, Authenticator=Basic} , Something happened
>>> at Authenticating Layer
>>> 5. -1234, [DEBUG], {sessionId=xyz, correlationId=null,
>>> serviceProvider=App1} , Leaving IdP Layer
>>> 6. -1234, [DEBUG], {sessionId=xyz, correlationId=null, } , Leaving
>>> Tomcat Layer
>>>
>>>
>>> What is happening here is the developer is given freedom to add/remove
>>> any contextual information to the current execution path. All the logs
>>> under that call stack prints the same contextual information(if we enable
>>> in log4j configuration). This will help debugging a support issue and do
>>> log analysis effectively.
>>>
>>> We do not need to restrict any variable at the platform layer. It should
>>> be extensible.
>>>
>>> Cheers,
>>> Ruwan
>>>
>>>
>>> On Tue, Aug 1, 2017 at 3:01 PM, Asma Jabir <as...@wso2.com> wrote:
>>>
>>>> Hi Ruwan,
>>>>
>>>> AFAIU, MDC which is known as ThreadContext in Log4J2 is used to support
>>>> multi-tenancy and is managed per thread [1]. In C4, for printing the
>>>> tenantId in the log message we have used
>>>> *CarbonContext.getThreadLocalCarbonContext().getTenantId()* from
>>>> org.wso2.carbon.utils [2] which achieves this.
>>>>
>>>> Nonetheless, if there are any required fields to be logged through
>>>> ThreadContext, yes, it can be incorporated by implementing ThreadContext
>>>> and the fields can be added in the log4j2 configuration file (e.g. [3]). We
>>>> may have to provide it as a fragment of 
>>>> ops4j.pax.logging.pax-logging-log4j2
>>>> to support OSGi. However, can you elaborate on the requirements so that we
>>>> can do further analysis to determine the importance of it.
>>>>
>>>> Thanks
>>>>
>>>> Regards,
>>>> Asma
>>>>
>>>> [1] https://logging.apache.org/log4j/2.x/manual/thread-context.html
>>>> [2] https://github.com/wso2/carbon-kernel/blob/4.4.x/core/or
>>>> g.wso2.carbon.utils/src/main/java/org/wso2/carbon/context/Ca
>>>> rbonContext.java
>>>> [3] http://howtodoinjava.com/log4j2/threadcontext-fish-tagging/
>>>>
>>>> On Mon, Jul 31, 2017 at 5:47 PM, Asma Jabir <as...@wso2.com> wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> Primarily, this is being done for performance reasons. Here are some
>>>>> pros and cons of migrating to Log4J 2.x
>>>>>
>>>>> Pros:
>>>>>
>>>>>    - Log4J2 is said to have improved performance with asynchronuous
>>>>>    loggers and appenders according to [1].
>>>>>    - Also there were several requests to migrate to Log4J2 and it has
>>>>>    been verified that Log4J2 is much faster than 1.x
>>>>>    - It has also been announced End-Of-Life for Log4J 1 and
>>>>>    recommends upgrade to Log4j 2 [2]
>>>>>
>>>>> Cons:
>>>>>
>>>>> The only drawback is that it is not backward compatible because of the
>>>>> replacement of log4j.properties with log4j2.properties and this too we are
>>>>> investigating of a way to programatically provide the configurations by
>>>>> reading the properties from the prevailing file and convert them to the 
>>>>> new
>>>>> format. If that succeeds, it will be backward compatible as well.
>>>>>
>>>>> @Ruwan
>>>>> Sure will look into this and will update.
>>>>>
>>>>> [1] https://logging.apache.org/log4j/2.x/manual/async.html#Performance
>>>>> [2] https://blogs.apache.org/foundation/entry/apache_logging
>>>>> _services_project_announces
>>>>>
>>>>> Thanks
>>>>>
>>>>> Regards
>>>>> Asma
>>>>>
>>>>> On Mon, Jul 31, 2017 at 5:03 PM, Ruwan Abeykoon <ruw...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> Hi All,
>>>>>> Can we consider introducing "Diagnostic Context" (e.g. [1] )while on
>>>>>> this effort ? which will improve our logging information considerably.
>>>>>>
>>>>>> [1] https://www.javacodegeeks.com/2013/01/effective-logging-in-j
>>>>>> avajee-mapped-diagnostic-context.html
>>>>>>
>>>>>> Cheers,
>>>>>> Ruwan
>>>>>>
>>>>>> On Mon, Jul 31, 2017 at 4:40 PM, KasunG Gajasinghe <kas...@wso2.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Jul 31, 2017 at 3:50 PM, KasunG Gajasinghe <kas...@wso2.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Asma,
>>>>>>>>
>>>>>>>> Can you explain why we need to do this from a user perspective?
>>>>>>>> What are the advantages/disavantages?
>>>>>>>>
>>>>>>>> Log4j does not support the Log4j properties file format. So, this
>>>>>>>> change is not backward-compatible.
>>>>>>>>
>>>>>>>> On Mon, Jul 31, 2017 at 2:53 PM, Asma Jabir <as...@wso2.com> wrote:
>>>>>>>>
>>>>>>>>> The logging framework for C4 will be implemented using pax-logging
>>>>>>>>> as illustrated in the simple diagram below.
>>>>>>>>>
>>>>>>>>> [image: Inline image 3]
>>>>>>>>>
>>>>>>>>> As shown above:
>>>>>>>>>
>>>>>>>>>    - org.wso2.carbon.logging will act as the Logging API
>>>>>>>>>    - *org.ops4j.pax.logging.pax-logging-log4j2.jar* will bridge
>>>>>>>>>    the logs to log4J2
>>>>>>>>>    - The custom appenders will be residing in a fragment of
>>>>>>>>>    *org.ops4j.pax.logging.pax-logging-log4j2*
>>>>>>>>>
>>>>>>>>> Also,
>>>>>>>>>
>>>>>>>>>    - pax-logging.properties file will be added which points to
>>>>>>>>>    the log4j2.properties file for configurations
>>>>>>>>>    - org.wso2.carbon.logging.propfile_1.0.0.jar will be removed
>>>>>>>>>    as it is no longer necessary to provide the configuration in the 
>>>>>>>>> classpath
>>>>>>>>>    of the org.wso2.carbon.logging
>>>>>>>>>
>>>>>>>>> Moreover, there is a log4j.properties file in
>>>>>>>>> org.wso2.carbon.server which is used for writing the logs before OSGi 
>>>>>>>>> is
>>>>>>>>> started. Also there is logging-bridge.properties file which is the
>>>>>>>>> configuration file used for JUL (java-util-logging). Therefore, 
>>>>>>>>> similar to
>>>>>>>>> C5, the following changes will be done in this module to reduce
>>>>>>>>> configuration files.
>>>>>>>>>
>>>>>>>>>    - Currently org.wso2.carbon.server uses JCL (commons-logging)
>>>>>>>>>    and this will be changed to JUL
>>>>>>>>>    - *This eliminates the need for a separate log4j configuration
>>>>>>>>>    file for org.wso2.carbon.server.* Thus log4j.properties
>>>>>>>>>    residing inside org.wso2.carbon.server will be removed
>>>>>>>>>    - This resolves [1]
>>>>>>>>>    - All the configurations related to org.wso2.carbon.server
>>>>>>>>>    will be written in
>>>>>>>>>    * $CARBON_HOME/repository/conf/etc/logging-bridge.properties*
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> We are looking forward to move forward with this method and
>>>>>>>>> appreciate your comments/suggestions on this.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Asma
>>>>>>>>>
>>>>>>>>> On Mon, Jul 17, 2017 at 11:38 AM, Asma Jabir <as...@wso2.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi
>>>>>>>>>>
>>>>>>>>>> We already have a central logging module in the kernel which is
>>>>>>>>>> org.wso2.carbon.logging [1] and that acts similar to the a Logging 
>>>>>>>>>> API. So
>>>>>>>>>> we can can continue to use it and all the logging specific 
>>>>>>>>>> dependencies and
>>>>>>>>>> imports will be residing here. But the custom appenders are located 
>>>>>>>>>> in
>>>>>>>>>> org.wso2.carbon.utils [2] since it is the first to get resolved and
>>>>>>>>>> therefore, this would have changes when re-writing the appenders. 
>>>>>>>>>> Overall,
>>>>>>>>>> the changes will be only inside the kernel and application will not 
>>>>>>>>>> need
>>>>>>>>>> any changes.
>>>>>>>>>>
>>>>>>>>>> Moreover, after further experimenting for approach 1 and 2 which
>>>>>>>>>> were implementable, the following were understood.
>>>>>>>>>>
>>>>>>>>>>    - When using plain log4j 2, it cannot be used with with the
>>>>>>>>>>    default functionality
>>>>>>>>>>       - The bridge from jcl-log4j is implemented using a
>>>>>>>>>>       ServiceLoader which needs special handling in OSGi environment 
>>>>>>>>>> [3].
>>>>>>>>>>       - Also this needs additional OSGi fragments as stated in
>>>>>>>>>>       point 2 in the first mail
>>>>>>>>>>       - The configuration file(log4j.properties) is currently
>>>>>>>>>>       packed to carbon logging using a fragmented bundle (
>>>>>>>>>>       org.wso2.carbon.logging.propfile_1.0.0.jar) - same method
>>>>>>>>>>       can be follwed for log4j2 or the file can be given through a 
>>>>>>>>>> system
>>>>>>>>>>       property which makes org.wso2.carbon.logging.propfile_1.0.0.jar
>>>>>>>>>>       unnecessary
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>    - Also, external .jar files are not able to find the logging
>>>>>>>>>>    implementation which we are still investigating as to why this 
>>>>>>>>>> happens
>>>>>>>>>>
>>>>>>>>>> The above had been happening since the log4j2 implementation was
>>>>>>>>>> not found in OSGi environment and it was not related to external 
>>>>>>>>>> jars.
>>>>>>>>>> Therefore, by providing the configuration files 
>>>>>>>>>> *log4j-provider.properties
>>>>>>>>>> *and *log4j2.properties,* in carbon-logging the issue was fixed.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>    - Pax-logging overcomes the above issues and therefore, the
>>>>>>>>>>    default pax-logging api can be used
>>>>>>>>>>       - This provides log4j2 bridge internally which will map
>>>>>>>>>>       any type of logging to log4j2
>>>>>>>>>>       - By replacing the log4j1 libraries with pax-logging and
>>>>>>>>>>       re-writing the appenders, this can be gotten to work
>>>>>>>>>>       - The properties file will be
>>>>>>>>>>       pax-logging.properties/log4j2.properties
>>>>>>>>>>       - The configuration file will be set as a system property
>>>>>>>>>>       - The org.wso2.carbon.logging.propfile_1.0.0.jar will not
>>>>>>>>>>       be needed therein
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> [1] https://github.com/wso2/carbon-kernel/tree/4.5.x/core/or
>>>>>>>>>> g.wso2.carbon.logging
>>>>>>>>>> [2] https://github.com/wso2/carbon-kernel/tree/4.5.x/core/or
>>>>>>>>>> g.wso2.carbon.utils/src/main/java/org/wso2/carbon/utils/logg
>>>>>>>>>> ing/appenders
>>>>>>>>>> [3] http://blog.osgi.org/2013/02/javautilserviceloader-in-os
>>>>>>>>>> gi.html
>>>>>>>>>>
>>>>>>>>>> <http://blog.osgi.org/2013/02/javautilserviceloader-in-osgi.html>
>>>>>>>>>>
>>>>>>>>>> <http://blog.osgi.org/2013/02/javautilserviceloader-in-osgi.html>
>>>>>>>>>> Regards,
>>>>>>>>>> Asma
>>>>>>>>>>
>>>>>>>>>> On Sat, Jul 15, 2017 at 11:57 PM, Ruwan Abeykoon <ruw...@wso2.com
>>>>>>>>>> > wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Irunika,
>>>>>>>>>>> In C4, applications use commons logging. We never wanted to use
>>>>>>>>>>> Log4J directly. Hence the architecture you proposed is already 
>>>>>>>>>>> there in C4.
>>>>>>>>>>> In C5 we use slf4j, in place of commons logging, which
>>>>>>>>>>> architecturally the same.
>>>>>>>>>>>
>>>>>>>>>>> Hence I do not see any value in introducing another WSO2
>>>>>>>>>>> specific logging framework/wrapper/etc.
>>>>>>>>>>>
>>>>>>>>>>> For the original ${subject}, would not it work simply using
>>>>>>>>>>> log4j2 library, removing all log4j 1 library with change in 
>>>>>>>>>>> log4j.property
>>>>>>>>>>> file appropriately?
>>>>>>>>>>> Yes, it needs to have a change in Carbon**Appenders to use
>>>>>>>>>>> log4j2 API, but this is only at Carbon-Logging module. I guess we 
>>>>>>>>>>> can have
>>>>>>>>>>> new version with log4j2.
>>>>>>>>>>> In short, IMO, there will be no change in applications, but may
>>>>>>>>>>> be little change in kernel implementation(which is transparent to 
>>>>>>>>>>> apps) in
>>>>>>>>>>> log4j2 migration.
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Ruwan
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Jul 14, 2017 at 3:37 PM, Irunika Weeraratne <
>>>>>>>>>>> irun...@wso2.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> 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 <+94%2071%20240%203314>*
>>>>>>>>>>>> *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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Asma Zinneera Jabir
>>>>>>>>>> Software Engineer
>>>>>>>>>> WSO2 Inc: http://wso2.com/
>>>>>>>>>> Contact No: +94 77 332 4752 <+94%2077%20332%204752>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Asma Zinneera Jabir
>>>>>>>>> Software Engineer
>>>>>>>>> WSO2 Inc: http://wso2.com/
>>>>>>>>> Contact No: +94 77 332 4752 <+94%2077%20332%204752>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> *Kasun Gajasinghe*Associate Technical Lead, WSO2 Inc.
>>>>>>>> email: kasung AT spamfree wso2.com
>>>>>>>> linked-in: http://lk.linkedin.com/in/gajasinghe
>>>>>>>> blog: http://kasunbg.org
>>>>>>>> phone: +1 650-745-4499 <+1%20650-745-4499>, 77 678 0813
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> *Kasun Gajasinghe*Associate Technical Lead, WSO2 Inc.
>>>>>>> email: kasung AT spamfree wso2.com
>>>>>>> linked-in: http://lk.linkedin.com/in/gajasinghe
>>>>>>> blog: http://kasunbg.org
>>>>>>> phone: +1 650-745-4499 <(650)%20745-4499>, 77 678 0813
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Asma Zinneera Jabir
>>>>> Software Engineer
>>>>> WSO2 Inc: http://wso2.com/
>>>>> Contact No: +94 77 332 4752 <+94%2077%20332%204752>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Asma Zinneera Jabir
>>>> Software Engineer
>>>> WSO2 Inc: http://wso2.com/
>>>> Contact No: +94 77 332 4752 <+94%2077%20332%204752>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> *Ruwan Abeykoon*
>>> *Associate Director/Architect**,*
>>> *WSO2, Inc. http://wso2.com <https://wso2.com/signature> *
>>> *lean.enterprise.middleware.*
>>>
>>>
>>
>>
>> --
>> Asma Zinneera Jabir
>> Software Engineer
>> WSO2 Inc: http://wso2.com/
>> Contact No: +94 77 332 4752 <+94%2077%20332%204752>
>>
>>
>>
>
>
> --
> Asma Zinneera Jabir
> Software Engineer
> WSO2 Inc: http://wso2.com/
> Contact No: +94 77 332 4752 <+94%2077%20332%204752>
>
>
>


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

Reply via email to