Hi Sameera, Could you please explain a bit more on technical difference on 1 and 2. As I could see, both looks the same in implementation and developer perspective.
@Manu, >>Can't we just use MDC [1]. Kernel can wrap it if needed, but I don’t see why. I think MDC ties us to Log4J in higher levels. I would vote for the CarbonContext to carry all the info which similar to MDC/NDC, in thread local, and do login with custom appenders. This way we are only tied to Logging framework at very low level. I think log analyzar can be enhanced to provide visualizations on audit logs. It would be nice if the log analytics bits are developed/released at the same time. Cheers, Ruwan On Fri, Apr 29, 2016 at 7:21 PM, Manuranga Perera <[email protected]> wrote: > But the problem is that each and every time a developer logs an audit >> log, he has to set contextual information. > > No need to set MDC each time. Just like CarbonContext approach we can set > it at login time, can't we? > > > On Fri, Apr 29, 2016 at 12:27 AM, Sameera Jayasoma <[email protected]> > wrote: > >> 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 <[email protected]> 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 <[email protected]> >>> 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: [email protected] >>>> 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 >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> With regards, >>> *Manu*ranga Perera. >>> >>> phone : 071 7 70 20 50 >>> mail : [email protected] >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Sameera Jayasoma, >> Software Architect, >> >> WSO2, Inc. (http://wso2.com) >> email: [email protected] >> 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 >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > With regards, > *Manu*ranga Perera. > > phone : 071 7 70 20 50 > mail : [email protected] > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Ruwan Abeykoon* *Architect,* *WSO2, Inc. http://wso2.com <http://wso2.com/> * *lean.enterprise.middleware.* email: [email protected]
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
