logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shorn Tolley <shorntol...@yahoo.co.uk>
Subject Re: Implementing auditing in log4j, was: Formal parameter ideas?
Date Thu, 17 Oct 2002 23:34:13 GMT

Isn't log4j finished with the AuditObject once the
call to ObjectRenderer.doRender(Object) call has been
made with that object as the parameter?  I was
thinking that at that point, the AuditObjectRenderer
could return the AuditObject to the pool.

Or is there other stuff going on within the framework?

Cheers,
Shorn.

 --- Ceki Gülcü <ceki@qos.ch> wrote: > 
> 
> 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>
>  

__________________________________________________
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>


Mime
View raw message