> > think MDC ties us to Log4J in higher levels
MDC is already warped by slf4j same as Logger class. So there is no risk of tightly coupling to log4j. Eg: import org.slf4j.MDC; import org.slf4j.Logger; import org.slf4j.LoggerFactory; On Mon, May 2, 2016 at 8:21 AM, Ruwan Abeykoon <[email protected]> wrote: > 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 > > -- 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
