logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject Re: Implementing auditing in log4j, was: Formal parameter ideas?
Date Thu, 17 Oct 2002 09:01:20 GMT


You can't pool AuditObjects because you can't know when log4j has
finished using them. You'd need to modify log4j code such that when
the AuditObject is really written to the output media the AuditObject
is returned to the pool.

If there were a standard pooling API log4j could have done it for you.

At 04:41 17.10.2002 +0100, you wrote:

>I'm thinking that perhaps "audit" is not the right
>term for what we're doing.
>
>We have to collect this data (business requirement);
>the data will be aggregated and reported with a
>dedicated reporting tool (probably CrystalReports).
>
>We also have to provide the ability to drill down to
>detailed data, so we have to store that information.
>
>That said, investigation of our application has
>revealed that expected usage is very low.  But I am
>wondering if this approach could be made to work
>efficiently in a high load situation too?  Then,
>whenever we come across this kind of situation, we can
>immediately propose to use Log4j in this way.
>
>I'm thinking about having an AuditObject pool that
>would reserve an AuditObject once a user requests one
>(which they can then use only once to log a single
>audit event), then the object would be put back in the
>pool when the event had been logged.
>
>Cheers,
>Shorn.
>
>  --- Ceki Gülcü <ceki@qos.ch> wrote: > At 08:12
>16.10.2002 +0100, you wrote:
> > >We are soon to be doing almost exactly that kind of
> > >thing on our project, for the purposes of auditing.
> > >
> > >We would like to use custom "AuditObjects" and
> > log4j
> > >as the audit trail API.  For the implementation of
> > the
> > >recording of the audting, we'd have custom
> > >"AuditObject" log4j renders and an Asynchronous
> > >appender linked to a JDBCAppender to write the
> > audit
> > >trail into the database.
> > >
> > >I'd be interested in hearing if anyone can state if
> > >this is maybe a really bad idea for some reason??
> > >
> > >I also am a bit worried about the overhead of
> > creating
> > >a short-lived "AuditObject" each time something
> > that
> > >needs to be audited occurs (potentially a lot).
> >
> > Creating massive amounts of audit data will defeat
> > the purpose of the
> > audit. If the generated info is too voluminous, no
> > one will be able to
> > read it without getting nauseous (literally). One
> > must exercise
> > discernment when logging/auditing. Under this angle,
> > the overhead of
> > the AuditObject becomes less important.
> >
> > >Cheers,
> > >Shorn.
> >
> > --
> > Ceki
> >
> > TCP implementations will follow a general principle
> > of robustness: be
> > conservative in what you do, be liberal in what you
> > accept from
> > others. -- Jon Postel, RFC 793
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:log4j-user-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> > <mailto:log4j-user-help@jakarta.apache.org>
> >
>
>__________________________________________________
>Do You Yahoo!?
>Everything you'll ever need on one web page
>from News and Sport to Email and Music Charts
>http://uk.my.yahoo.com
>
>--
>To unsubscribe, e-mail:   <mailto:log4j-user-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:log4j-user-help@jakarta.apache.org>

--
Ceki

TCP implementations will follow a general principle of robustness: be
conservative in what you do, be liberal in what you accept from
others. -- Jon Postel, RFC 793



--
To unsubscribe, e-mail:   <mailto:log4j-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:log4j-user-help@jakarta.apache.org>


Mime
View raw message