Yes. We were looking into the ThreadContext class provided by Log4j. But
the problem is that each and every time a developer logs an audit log, he
has to set contextual information. We can avoid this by setting required
details to the CarbonContext at the time of login in.
On Thu, Apr 28, 2016 at 8:14 PM, Manuranga Perera <m...@wso2.com> wrote:
> Hi,
>
> Can't we just use MDC [1]. Kernel can wrap it if needed, but I don’t see
> why.
>
> try {
>
> MDC.put("reg-resource",resource.getId());
>
> // do actual work with current resource
>
> } finally {
>
> try {
>
> MDC.remove("reg-resource");
>
> } catch (Exception ex) {
>
> //ignore, just catching so IDE wan't complain. MDC will never throw an
> IllegalArgumentException.
>
> }
>
> }
>
> As for appending, we can write a custom layout that iterates through all
> MDC values and log them. I think some build-in layouts already do this [2],
> not sure.
>
> BTW, I think we should look at logging JSON if possible. This will make
> DAS analysis of data much easier.
>
>
>
> [1] https://logging.apache.org/log4j/2.x/manual/thread-context.html
>
> [2]
> https://logging.apache.org/log4j/2.x/log4j-core/apidocs/org/apache/logging/log4j/core/layout/JsonLayout.html
>
> On Thu, Apr 28, 2016 at 4:39 AM, Sameera Jayasoma <same...@wso2.com>
> wrote:
>
>> Hi All,
>>
>> Audit logs or Audit trails contain set of log entries which describe a
>> sequence of actions which have occurred over a time period. From audit
>> logs, it is possible to trace all the actions of a single user or all the
>> actions or changes introduced to a certain module in the system etc. E.g.
>> It captures all the actions of a single user from the point he logs in to
>> the application.
>>
>> In previous versions of the Carbon platform, we only had a logger called
>> AUDIT and a separate appender which appends audit logs to separate log
>> file.
>>
>> The only drawback of this approach is that we don't have a proper way to
>> capture contextual information. In each and every audit log, we need to
>> capture logged in user details, IP address of client etc. In the previous
>> approach developers have to log this information with each and every audit
>> log attempt. This is suboptimal IMO, we need to implement a mechanism where
>> developers gives only the log message and system should append all the
>> other information to the log. I see few ways to implement this.
>>
>> 1) Write a custom appender which write audit logs to the file with
>> contextual information.
>> 2) Provide API to log audit logs. We can extract contextual information
>> from the CarbonContext in both of these methods.
>>
>> Any thoughts.
>>
>> Thanks,
>> Sameera.
>>
>> --
>> Sameera Jayasoma,
>> Software Architect,
>>
>> WSO2, Inc. (http://wso2.com)
>> email: same...@wso2.com
>> blog: http://blog.sameera.org
>> twitter: https://twitter.com/sameerajayasoma
>> flickr: http://www.flickr.com/photos/sameera-jayasoma/collections
>> Mobile: 0094776364456
>>
>> Lean . Enterprise . Middleware
>>
>>
>> _______________________________________________
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> With regards,
> *Manu*ranga Perera.
>
> phone : 071 7 70 20 50
> mail : m...@wso2.com
>
> _______________________________________________
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
Sameera Jayasoma,
Software Architect,
WSO2, Inc. (http://wso2.com)
email: same...@wso2.com
blog: http://blog.sameera.org
twitter: https://twitter.com/sameerajayasoma
flickr: http://www.flickr.com/photos/sameera-jayasoma/collections
Mobile: 0094776364456
Lean . Enterprise . Middleware
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
