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 Shorn Tolley <sh...@yahoo.co.uk> on 2002/10/16 09:12:01 UTC
Implementing auditing in log4j, was: Formal parameter ideas?
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).
Does anyone have any input on this subject?
Cheers,
Shorn.
--- Rick LaBanca <ri...@studentuniverse.com>
wrote: > Yes that's what I was thinking of doing also.
But
> then I think, why no go
> the extra step and have the parameter class wrap the
> correct logger. I think
> I am leaning that way. Plus I'm performance paranoid
> for some of the logs,
> want to just reuse objects as much as I can.
>
> ----- Original Message -----
> From: "Shorn Tolley" <sh...@yahoo.co.uk>
> To: "Log4J Users List"
> <lo...@jakarta.apache.org>
> Sent: Monday, October 14, 2002 9:33 PM
> Subject: Re: Formal parameter ideas?
>
>
> > What about encapsulating your formal parameters in
> a
> > single object, then having a log4j object renderer
> to
> > format that object?
> >
> > Something like this:
> > FormalParams fp =
> > new FormalParams("johndoe","14.95","software");
> > mycartlog.info(fp);
> >
> > Doesn't stop people from logging whatever they
> want,
> > but when they want to specifically log a set of
> > "Formal Parameters", as long as they use the
> > FormalParams class, they can't mess it up.
> (becuase
> > it's the object renderer that does the formatting,
> not
> > the caller).
> >
> > Just a thought.
> >
> > Cheers,
> > Shorn.
> >
> >
> > --- "LaBanca, Rick"
> > <ri...@studentuniverse.com> wrote: >
> > > I want to impose some formal parameters on
> logging.
> > > By that I mean,
> > > mycartlog.info("johndoe","14.95","software");
> etc,
> > > and stamp that into the
> > > log in a known (and more parseable) format.
> > >
> > > I wish to reduce the risk of someone making a
> logger
> > > and not formatting
> > > correctly so this idea came up. I could wrap
> > > loggers, and make these
> > > methods. Or I could make helpers that take
> > > parameters and string 'em up, but
> > > there is a chance there that the wrong helper
> could
> > > be used for the wrong
> > > log instance. Confused yet?
> > >
> > > Perhaps I am trying to be too safe... Anyone do
> > > something similar?
> > >
> > > Rick
> > >
> > > --
> > > 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>
>
>
> --
> 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>.
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>
Re: Implementing auditing in log4j, was: Formal parameter
ideas?
Posted by Ceki Gülcü <ce...@qos.ch>.
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>