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 23:43:36 GMT

At 00:34 18.10.2002 +0100, you wrote:

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

Usually that is the case unless you are using the AsyncAppender.

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

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