Hi Chad, I'm sorry to say no, my customer doesn't share code. Especially not for this component. But due to the good design of logback this was very straight forward. As I said, I used logback-core and implemented a few classes on top of this. I found looking at how things were solved in logback-classic and logback-access very helpful. I ran into a few problems when extending some classes for our specific needs, but I filed jiras regarding that and I believe it has been fixed in 0.9.10/11.
What I could do is sharing some kind of UML class diagram to show the idea. I'll look at that on Monday. /Anders On Fri, Oct 31, 2008 at 9:45 AM, Chad La Joie <[EMAIL PROTECTED]> wrote: > Hey Anders, > > Do you have any code that you could share that shows how you did the > event-based audit logging vs the standard level-based? > > Anders Hammar wrote: >> I was asked by Ceki to share my successful Logback story with you all. >> >> In a former assignment for one of our customers, we implemented an >> audit component. The customer is to use this component in their >> applications to audit end-user activities. >> >> In some earlier application specific audit implementations, log4j had >> been used. However, log4j (and pretty much all existing application >> logging frameworks that I looked at) has the notion of logging levels. >> For auditing (at least in this customer's case) we have actions/events >> which have no relation between them. So, having levels of debug, info, >> warn, etc isn't right but we rather have independent events. >> When I found Logback it was kind of love at first sight, the modular >> design fitted beautifully with what we wanted and we chose Logback >> (specifically logback-core) for our actual audit logging. We based >> this choice on two factors in specific: >> 1. The possibility of log on actions/events rather than levels (as >> above described) >> 2. The possiblity of having several independently configured logback >> instances. (This is not possible with log4j for instance, and as the >> customer's app server of choice uses log4j we would need to combine >> application logging and audit logging configuration - which is not >> good out of security perspective.) >> >> Also, the extensive documentation made my work easy to recommend the >> framework. As we all know, good documentation is not always the case >> in OSS. However, as mentioned on the mailing list earlier, the lack of >> a 1.0 release could have been a problem. However, Ceki's track record >> (with log4j) made me feel safe still going with Logback. >> >> As i personally strongly believe in OSS I normally participate and >> contribute to the community of the libs I use. However, working as a >> consultant I just can't be involved in everything and tend to only >> stay active as long as the assignment lasts (there are a few >> exceptions). Therefore I don't subscribe to this mailing list any >> longer, but I will monitor this thread so if you have any questions >> regarding my use case I'll be happy to answer them. >> >> /Anders >> _______________________________________________ >> Logback-user mailing list >> [email protected] >> http://qos.ch/mailman/listinfo/logback-user > > -- > SWITCH > Serving Swiss Universities > -------------------------- > Chad La Joie, Software Engineer, Net Services > Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland > phone +41 44 268 15 75, fax +41 44 268 15 68 > [EMAIL PROTECTED], http://www.switch.ch > > _______________________________________________ > Logback-user mailing list > [email protected] > http://qos.ch/mailman/listinfo/logback-user > _______________________________________________ Logback-user mailing list [email protected] http://qos.ch/mailman/listinfo/logback-user
