You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Ceki Gülcü <ce...@qos.ch> on 2002/10/16 10:51:41 UTC
Re: Implementing auditing in log4j, was: Formal parameter
ideas?
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Implementing auditing in log4j, was: Formal parameter
ideas?
Posted by Ceki Gülcü <ce...@qos.ch>.
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ü <ce...@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ü <ce...@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:
> > > >
> > <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > > <ma...@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:
> > <ma...@jakarta.apache.org>
> > >For additional commands, e-mail:
> > <ma...@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:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@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: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Implementing auditing in log4j, was: Formal parameter ideas?
Posted by Shorn Tolley <sh...@yahoo.co.uk>.
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ü <ce...@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ü <ce...@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:
> > >
> <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > > <ma...@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:
> <ma...@jakarta.apache.org>
> >For additional commands, e-mail:
> <ma...@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:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Implementing auditing in log4j, was: Formal parameter
ideas?
Posted by Ceki Gülcü <ce...@qos.ch>.
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ü <ce...@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:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@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: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Implementing auditing in log4j, was: Formal parameter ideas?
Posted by Shorn Tolley <sh...@yahoo.co.uk>.
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ü <ce...@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:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>