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
Thank you Anders. Much appreciated. 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 Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch
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 Logback-user@qos.ch 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 chad.lajoie@switch.ch, http://www.switch.ch
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 <chad.lajoie@switch.ch> 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 Logback-user@qos.ch 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 chad.lajoie@switch.ch, http://www.switch.ch
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
Thanks. We use Logback for a product with modestly large deployment. I have an audit log now but I'm not entirely happy with it. Event-based log entries would be a large step in the right direction. Anders Hammar wrote:
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 <chad.lajoie@switch.ch> 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 Logback-user@qos.ch 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 chad.lajoie@switch.ch, http://www.switch.ch
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@qos.ch 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 chad.lajoie@switch.ch, http://www.switch.ch
I'm working on an OSGI client/server solution: * Equinox as OSGI framework * Eclipse Riena for Remote OSGI services, ObjectTransactions, UI * EasyBeans as OSGI EJB3 - container * Hibernate (JPA) * Eclipse RCP * SLF4J / LOGBack * BusinessProcesses (jBPM) and BusinessRules (Drools) * Eclipse (IDE, PDE, P2) * Eclipse Modeling (openArchitectureWare, EMF, UML2) *... just finished part 5 of my blog series "Logging in OSGI Enterprise Applications": http://ekkes-corner.blogspot.com/2008/10/logging-in-osgi-enterprise-applicat... Part 1: An overview Part 2: How to catch all log events from "classic" logging - frameworks Part 3: How to catch all log events from OSGI Log Services Part 4: How to start logging bundles the right way inside an OSGI Enterprise application Part 5: Configuration, Fragment-Bundles, Markers there will be more in the future (Why LOGBack was choosen, Tooling / Eclipse PlugIns / Lilith) ... now I'm also starting a NEW blog series "HowTo build an Equinox-Riena-EasyBeans-OSGI-Server" if you follow this new blog series you'll get an OpenSource OSGI Server combining Riena and EasyBeans under Equinox - of course logging done with LOGBack ekke blog in english: http://ekkes-corner.org blog in german: http://ekkes-ecke.org
Hello ekke, I have not read your blog series but intend to. However, my immediate knee jerk reaction is that, from what I can tell, there is no place where one can access the blog series in a *chronological* order. Towards the end of http://ekkes-corner.blogspot.com/2008/10/logging-in-osgi-enterprise-applicat... there is the header "Blog Series "Logging in OSGI Enterprise Applications" but to reach that point I have to go through the 5th entry in series which yields an reverse chronological order, which is somewhat confusing. Is there a page the series is listed/accessible in order? ekkehard wrote:
I'm working on an OSGI client/server solution:
* Equinox as OSGI framework * Eclipse Riena for Remote OSGI services, ObjectTransactions, UI * EasyBeans as OSGI EJB3 - container * Hibernate (JPA) * Eclipse RCP * SLF4J / LOGBack * BusinessProcesses (jBPM) and BusinessRules (Drools)
* Eclipse (IDE, PDE, P2)
* Eclipse Modeling (openArchitectureWare, EMF, UML2)
*...
just finished part 5 of my blog series
"Logging in OSGI Enterprise Applications": http://ekkes-corner.blogspot.com/2008/10/logging-in-osgi-enterprise-applicat...
Part 1: An overview Part 2: How to catch all log events from "classic" logging - frameworks Part 3: How to catch all log events from OSGI Log Services Part 4: How to start logging bundles the right way inside an OSGI Enterprise application Part 5: Configuration, Fragment-Bundles, Markers there will be more in the future (Why LOGBack was choosen, Tooling / Eclipse PlugIns / Lilith)
... now I'm also starting a NEW blog series
"HowTo build an Equinox-Riena-EasyBeans-OSGI-Server"
if you follow this new blog series you'll get an OpenSource OSGI Server combining Riena and EasyBeans under Equinox - of course logging done with LOGBack
ekke
blog in english: http://ekkes-corner.org blog in german: http://ekkes-ecke.org _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch
Ceki Gulcu schrieb:
Hello ekke,
I have not read your blog series but intend to. However, my immediate knee jerk reaction is that, from what I can tell, there is no place where one can access the blog series in a *chronological* order.
Towards the end of http://ekkes-corner.blogspot.com/2008/10/logging-in-osgi-enterprise-applicat... there is the header "Blog Series "Logging in OSGI Enterprise Applications" but to reach that point I have to go through the 5th entry in series which yields an reverse chronological order, which is somewhat confusing.
Is there a page the series is listed/accessible in order?
good point, ceki, I'll add this thanks for the hint ekke
Ceki Gulcu schrieb:
Hello ekke,
I have not read your blog series but intend to. However, my immediate knee jerk reaction is that, from what I can tell, there is no place where one can access the blog series in a *chronological* order.
http://ekkes-corner.blogspot.com/2008/10/index-blogseries-logging-in-osgi.ht... thx again ekke
Hi, Attached is a UML class diagram of the basics of the audit logger implementation utilizing Logback. As you can see it's not very complicated. What I have left out is most of the Joran configuration parts (you don't need to use Joran for configuration if you don't want to) and our extension of PatternLayoutBase (which uses a bunch of Converters specific to our case). Once again, have a look at logback-access for instance and it shouldn't be to hard to figure out. /Anders On Fri, Oct 31, 2008 at 1:21 PM, Chad La Joie <chad.lajoie@switch.ch> wrote:
Thanks. We use Logback for a product with modestly large deployment. I have an audit log now but I'm not entirely happy with it. Event-based log entries would be a large step in the right direction.
Anders Hammar wrote:
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 <chad.lajoie@switch.ch> 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 Logback-user@qos.ch 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 chad.lajoie@switch.ch, http://www.switch.ch
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@qos.ch 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 chad.lajoie@switch.ch, http://www.switch.ch
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
It would be nice to know what is in your AuditEvent. I suspect that is where our implementations differ. On Sun, Nov 2, 2008 at 11:42 AM, Anders Hammar <anders@hammar.net> wrote:
Hi,
Attached is a UML class diagram of the basics of the audit logger implementation utilizing Logback. As you can see it's not very complicated. What I have left out is most of the Joran configuration parts (you don't need to use Joran for configuration if you don't want to) and our extension of PatternLayoutBase (which uses a bunch of Converters specific to our case).
Once again, have a look at logback-access for instance and it shouldn't be to hard to figure out.
/Anders
On Fri, Oct 31, 2008 at 1:21 PM, Chad La Joie <chad.lajoie@switch.ch> wrote:
Thanks. We use Logback for a product with modestly large deployment. I have an audit log now but I'm not entirely happy with it. Event-based log entries would be a large step in the right direction.
Anders Hammar wrote:
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 <chad.lajoie@switch.ch> 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 Logback-user@qos.ch 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 chad.lajoie@switch.ch, http://www.switch.ch
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@qos.ch 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 chad.lajoie@switch.ch, http://www.switch.ch
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
Hi, It contains what you need for your audit logging. The type is an enum which defines what kind of audit event it is. Other than that I can't go into details. But, one could guess that stuff like user, time, user action details would be logged... /Anders On Mon, Nov 3, 2008 at 3:14 PM, ralph.goers @dslextreme.com <rgoers@apache.org> wrote:
It would be nice to know what is in your AuditEvent. I suspect that is where our implementations differ.
On Sun, Nov 2, 2008 at 11:42 AM, Anders Hammar <anders@hammar.net> wrote:
Hi,
Attached is a UML class diagram of the basics of the audit logger implementation utilizing Logback. As you can see it's not very complicated. What I have left out is most of the Joran configuration parts (you don't need to use Joran for configuration if you don't want to) and our extension of PatternLayoutBase (which uses a bunch of Converters specific to our case).
Once again, have a look at logback-access for instance and it shouldn't be to hard to figure out.
/Anders
On Fri, Oct 31, 2008 at 1:21 PM, Chad La Joie <chad.lajoie@switch.ch> wrote:
Thanks. We use Logback for a product with modestly large deployment. I have an audit log now but I'm not entirely happy with it. Event-based log entries would be a large step in the right direction.
Anders Hammar wrote:
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 <chad.lajoie@switch.ch> 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 Logback-user@qos.ch 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 chad.lajoie@switch.ch, http://www.switch.ch
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@qos.ch 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 chad.lajoie@switch.ch, http://www.switch.ch
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
Thanks Anders. Anders Hammar wrote:
Hi,
Attached is a UML class diagram of the basics of the audit logger implementation utilizing Logback. As you can see it's not very complicated. What I have left out is most of the Joran configuration parts (you don't need to use Joran for configuration if you don't want to) and our extension of PatternLayoutBase (which uses a bunch of Converters specific to our case).
Once again, have a look at logback-access for instance and it shouldn't be to hard to figure out.
/Anders
On Fri, Oct 31, 2008 at 1:21 PM, Chad La Joie <chad.lajoie@switch.ch> wrote:
Thanks. We use Logback for a product with modestly large deployment. I have an audit log now but I'm not entirely happy with it. Event-based log entries would be a large step in the right direction.
Anders Hammar wrote:
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 <chad.lajoie@switch.ch> 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 Logback-user@qos.ch 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 chad.lajoie@switch.ch, http://www.switch.ch
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@qos.ch 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 chad.lajoie@switch.ch, http://www.switch.ch
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
------------------------------------------------------------------------
_______________________________________________ Logback-user mailing list Logback-user@qos.ch 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 chad.lajoie@switch.ch, http://www.switch.ch
I also use Logback for audit logging. I'd be happy to share the code. I'll put together a zip and add it somewhere next week. Logically, it was part of what is now the XLogger class. I didn't add it because I believed it was specific to my employer. Ralph Anders Hammar wrote:
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
Maybe all this info should be added to the logback doc page. What do you think Ceki? /Anders On Fri, Oct 31, 2008 at 3:47 PM, Ralph Goers <ralph.goers@dslextreme.com> wrote:
I also use Logback for audit logging. I'd be happy to share the code. I'll put together a zip and add it somewhere next week. Logically, it was part of what is now the XLogger class. I didn't add it because I believed it was specific to my employer.
Ralph
Anders Hammar wrote:
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
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
I think logback should have a wiki so that users can freely enter logback related information. Anders Hammar wrote:
Maybe all this info should be added to the logback doc page. What do you think Ceki?
/Anders
On Fri, Oct 31, 2008 at 3:47 PM, Ralph Goers <ralph.goers@dslextreme.com> wrote:
I also use Logback for audit logging. I'd be happy to share the code. I'll put together a zip and add it somewhere next week. Logically, it was part of what is now the XLogger class. I didn't add it because I believed it was specific to my employer.
Ralph
Anders Hammar wrote:
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 -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch
participants (6)
-
Anders Hammar -
Ceki Gulcu -
Chad La Joie -
ekkehard -
Ralph Goers -
ralph.goers ＠dslextreme.com