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 Larry Young <ly...@dalmatian.com> on 2003/07/31 01:25:08 UTC
discreet log types
Hello,
I'm looking at creating a logging package for our applications
(web & non-web). The reason for yet-another-logger is that I want
discreet logging types, not hierarchical levels. I've built this kind of a
package before for previous projects, and ended up building the whole thing
because I didn't think log4j could do what I wanted (that was several years
ago). Now I'm building another one, and looking at the current version of
log4j, and having read much of Ceki's book (which I highly recommend!), I'm
thinking that there's got to be a way of re-configuring (bending?) log4j to
do what I need. I don't think it's that far off.
Basically, I want to be able to enable/disable logging for a
particular class or package by type, and each type is totally independent
of every other type. Some examples of types might be: Fatal, Error,
Timing, CodeBlock, ControlPoint, DBAccess, Info, etc. There is no implicit
"ordering" between these various types, so "levels" are inappropriate. What
I want to be able to do is to turn on/off each type independently, so that
I can turn on Timing without having to also turn on Info, or be able to
turn on CodeBlock without turning on Error. I also want the users of my
package to be able to define additional types and register them with the
logger at runtime (via code or xml ???). Oh yeah, I also need to have the
logger reload the config file (or some portion of it) on a regular basis so
that we can change the enabled types without bouncing the app-server or
restarting the application.
I was thinking if I tried to tie all my "types" to a single
"level", and did something with the log-level filtering to enable/disable
by package or class, that would get me close. I'm not sure how I'd tie in
the "type". I'd probably have to programatically update the log-level
filters with updates to handle config changes at runtime.
Thoughts, ideas, concerns??? Any comments are gratefully
accepted! :)
--- regards ---
Larry
--------------------------
Larry Young
The Dalmatian Group
www.dalmatian.com
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
Re: discreet log types
Posted by Larry Young <ly...@dalmatian.com>.
Paul,
Thanks for the response. Let me repeat back to you what I think
you are saying to be sure I understand.
Basically you are using MDC (I don't think NDC would be quite
right, and not sure what Properties are in this context) to add a
"user-specified" attribute to each logging call. Since MDC preserves these
per-thread, they would only apply to the caller's data. I'm assuming that
the MDC data is available in the LoggingEvent object (I know NDC is). So
assuming that the "log type" is the data put into the MDC, then the Filter
can check that against the current setting for that type, but it will still
have to scan the package hierarchy programmatically to see if that type is
enabled for the calling class. This might be a problem with nested timing
blocks if I try to use MDC for the timing info also, I need to give that
some more thought. Perhaps that is where NDC would come in handy.
If that's not what you were suggesting, please correct as
necessary. Otherwise, I'll give that a try!
--- regards ---
Larry
At 09:31 AM 7/31/03 +1000, you wrote:
>Hi Larry,
>
>This is where you would probably delve into the MDC/NDC/Properties
>usage.
>
>At each 'type' point/location in code I would add a MDC/NDC/Property
>(whatever works best) at the point, and remove it afterwards where
>appropriate. The log events generated between these places would then
>have a Level, belong to a Logger (you're class/interface/logger name),
>and have additional information for your 'type'.
>
>Then it is just a matter of configuring Filters at the appender level to
>filter out events that you're not interested in for that appender. You
>might have to develop some custom Filter classes to meet your needs, or
>re-use/build on the Filter classes that are in Log4j, but that's the
>approach I would use.
>
>Configuration reloading is free out of the box, just register a File
>Watchdog (see the PropertyConfigurator.configureAndWatch(file,
>watchTime) method, plus the DOMConfigurator obviously has this too).
>
>I hope this helps you.
>
>cheers,
>
>Paul Smith
>
>On Thu, 2003-07-31 at 09:25, Larry Young wrote:
> > Hello,
> >
> > I'm looking at creating a logging package for our applications
> > (web & non-web). The reason for yet-another-logger is that I want
> > discreet logging types, not hierarchical levels. I've built this kind
> of a
> > package before for previous projects, and ended up building the whole
> thing
> > because I didn't think log4j could do what I wanted (that was several
> years
> > ago). Now I'm building another one, and looking at the current version of
> > log4j, and having read much of Ceki's book (which I highly recommend!),
> I'm
> > thinking that there's got to be a way of re-configuring (bending?)
> log4j to
> > do what I need. I don't think it's that far off.
> >
> > Basically, I want to be able to enable/disable logging for a
> > particular class or package by type, and each type is totally independent
> > of every other type. Some examples of types might be: Fatal, Error,
> > Timing, CodeBlock, ControlPoint, DBAccess, Info, etc. There is no
> implicit
> > "ordering" between these various types, so "levels" are inappropriate.
> What
> > I want to be able to do is to turn on/off each type independently, so that
> > I can turn on Timing without having to also turn on Info, or be able to
> > turn on CodeBlock without turning on Error. I also want the users of my
> > package to be able to define additional types and register them with the
> > logger at runtime (via code or xml ???). Oh yeah, I also need to have the
> > logger reload the config file (or some portion of it) on a regular
> basis so
> > that we can change the enabled types without bouncing the app-server or
> > restarting the application.
> >
> > I was thinking if I tried to tie all my "types" to a single
> > "level", and did something with the log-level filtering to enable/disable
> > by package or class, that would get me close. I'm not sure how I'd tie in
> > the "type". I'd probably have to programatically update the log-level
> > filters with updates to handle config changes at runtime.
> >
> > Thoughts, ideas, concerns??? Any comments are gratefully
> > accepted! :)
> >
> > --- regards ---
> > Larry
> >
> >
> > --------------------------
> > Larry Young
> > The Dalmatian Group
> > www.dalmatian.com
> >
> >
--------------------------
Larry Young
The Dalmatian Group
www.dalmatian.com
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
Re: discreet log types
Posted by Paul Smith <pa...@lawlex.com.au>.
Hi Larry,
This is where you would probably delve into the MDC/NDC/Properties
usage.
At each 'type' point/location in code I would add a MDC/NDC/Property
(whatever works best) at the point, and remove it afterwards where
appropriate. The log events generated between these places would then
have a Level, belong to a Logger (you're class/interface/logger name),
and have additional information for your 'type'.
Then it is just a matter of configuring Filters at the appender level to
filter out events that you're not interested in for that appender. You
might have to develop some custom Filter classes to meet your needs, or
re-use/build on the Filter classes that are in Log4j, but that's the
approach I would use.
Configuration reloading is free out of the box, just register a File
Watchdog (see the PropertyConfigurator.configureAndWatch(file,
watchTime) method, plus the DOMConfigurator obviously has this too).
I hope this helps you.
cheers,
Paul Smith
On Thu, 2003-07-31 at 09:25, Larry Young wrote:
> Hello,
>
> I'm looking at creating a logging package for our applications
> (web & non-web). The reason for yet-another-logger is that I want
> discreet logging types, not hierarchical levels. I've built this kind of a
> package before for previous projects, and ended up building the whole thing
> because I didn't think log4j could do what I wanted (that was several years
> ago). Now I'm building another one, and looking at the current version of
> log4j, and having read much of Ceki's book (which I highly recommend!), I'm
> thinking that there's got to be a way of re-configuring (bending?) log4j to
> do what I need. I don't think it's that far off.
>
> Basically, I want to be able to enable/disable logging for a
> particular class or package by type, and each type is totally independent
> of every other type. Some examples of types might be: Fatal, Error,
> Timing, CodeBlock, ControlPoint, DBAccess, Info, etc. There is no implicit
> "ordering" between these various types, so "levels" are inappropriate. What
> I want to be able to do is to turn on/off each type independently, so that
> I can turn on Timing without having to also turn on Info, or be able to
> turn on CodeBlock without turning on Error. I also want the users of my
> package to be able to define additional types and register them with the
> logger at runtime (via code or xml ???). Oh yeah, I also need to have the
> logger reload the config file (or some portion of it) on a regular basis so
> that we can change the enabled types without bouncing the app-server or
> restarting the application.
>
> I was thinking if I tried to tie all my "types" to a single
> "level", and did something with the log-level filtering to enable/disable
> by package or class, that would get me close. I'm not sure how I'd tie in
> the "type". I'd probably have to programatically update the log-level
> filters with updates to handle config changes at runtime.
>
> Thoughts, ideas, concerns??? Any comments are gratefully
> accepted! :)
>
> --- regards ---
> Larry
>
>
> --------------------------
> Larry Young
> The Dalmatian Group
> www.dalmatian.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: log4j-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
Re: discreet log types
Posted by Ceki Gülcü <ce...@qos.ch>.
At 11:10 PM 8/14/2003 +0200, Ceki Gülcü wrote:
>If it can run, it can also walk!
>
>I think the existing system can be made to closely simulate the behavior
>you describe.
>
>Here is how:
>
>- Set the root logger to the level OFF.
>
>- Name your loggers as "fatal", "error", "timing", "CodeBlock",
>"ControlPoint", "DBAccess", "Info", etc. Set their levels to OFF when you
>create them.
>
>- Whenever you can any of the above loggers, call it with the same
>printing metdod, say info(Object message) of the org.apache.log4j.Logger class.
Whenever you *call* any ....
Sorry about that.
--
Ceki For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
Re: discreet log types
Posted by Eduardo Francos <ef...@incontext.fr>.
Larry Young wrote on 08/15/2003 03:12 AM:
> Paul,
>
> Yes, actually I had already gone down that road as one of my
> first solutions before I posted my original message. However, when I
> considered that option, I was appending the logging type, which was a
> problem when trying to specify packages instead of individual classes.
> But your suggestion to put it at the beginning could solve that problem.
>
> I'm not so worried about it being clumsy because I can always
> hide it with a wrapper around the front-end if necessary (i.e. create a
> static factory-like method). And I would only have to define loggers
> for the logging types that my class would be using, not necessarily
> every one that is defined, especially since the list needs to be
> extensible. And it would also allow me to enable multiple logging types
> for a single class/package.
>
> I'll have to give this one some more thought! It's not the
> cleanest of solutions, but if no one else on the list thinks this would
> be a good feature to have, then perhaps this would be the quickest
> solution for my situation. Thanks again for your ideas!
>
> --- regards ---
> Larry
>
>
>
> At 10:51 AM 8/15/03 +1000, you wrote:
>
>> On Fri, 2003-08-15 at 10:52, Larry Young wrote:
>> > Paul,
>> >
>> > Yes, I need to be able to specify which class may display
>> which
>> > set of discreet types. For example, I might have "com.*" allowed to
>> > display ERROR, but then override that for "com.xyz.MyClass" to
>> display only
>> > TIMING, "com.abc.def.*" to display METHOD_TRACE & TIMING, and
>> > "com.abc.dataaccess.*" to display DB_ACCESS.
>>
>> <snip/>
>>
>> Yeah, the more I think about it the more I see the issue. Ouch.
>>
>> Ok, since in each class you like have something like this:
>>
>> public static final Logger LOG = Logger.getLogger(MyClass.class);
>>
>> Could you do something like this? (Cumbersome still, but hey, if you
>> want Ultimate Configuration it comes with Ultimate complexity usually
>>
>> public static final DBLogger = Logger.getLogger("DB." +
>> MyClass.class.getName() );
>>
>> public static final TimerLogger= Logger.getLogger("Trace." +
>> MyClass.class.getName());
>>
>> ...
>>
>> That way you will have a Logger for every class and every aspect. You
>> can then turn _ALL_ Trace logging by setting the "DB" Logger to whatever
>> level, then all the class names inherit from it. You can then also set
>> "DB" to INFO, but override with "DB.com.mycompany.MyClass=DEBUG".
>>
>> Would that help?
>>
>> cheers,
>>
>> Paul
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: log4j-user-help@jakarta.apache.org
>
>
> --------------------------
> Larry Young
> The Dalmatian Group
> www.dalmatian.com
I believe your concern will be covered in Log4j 1.3 under the topic
Logging Domains. It's described in the plan as "a very powerful and
innovative concept that extends the notion of hierarchical loggers. It
will also allow dynamic logging with pin-point accuracy"
I cannot be sure of this because there isn't much written on the subject
but I remember a discussion about it somewhere (sorry, I don't remember
where) that described logging domains in a way tha would cover the needs
of your discreet types.
Eduardo
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
Re: discreet log types
Posted by Paul Smith <pa...@lawlex.com.au>.
> Yes, actually I had already gone down that road as one of my first
> solutions before I posted my original message. However, when I considered
> that option, I was appending the logging type, which was a problem when
> trying to specify packages instead of individual classes. But your
> suggestion to put it at the beginning could solve that problem.
As I was writing my last message I also started with it at the end, and
realised the same thing you have. I think it has more power at the
front. Log4j does not have a complete taxonomy, it is strictly
hierarchical, so you will ALWAYS have to choose a primary node structure
at the top (this is usually the package name hierarchy). It sounds like
your "aspect" (DB, TRACE) etc is your primary concern, with a secondary
concern of the source class.
> I'm not so worried about it being clumsy because I can always hide
> it with a wrapper around the front-end if necessary (i.e. create a static
> factory-like method). And I would only have to define loggers for the
> logging types that my class would be using, not necessarily every one that
> is defined, especially since the list needs to be extensible. And it would
> also allow me to enable multiple logging types for a single class/package.
>
> I'll have to give this one some more thought! It's not the
> cleanest of solutions, but if no one else on the list thinks this would be
> a good feature to have, then perhaps this would be the quickest solution
> for my situation. Thanks again for your ideas!
Feel free to discuss your ideas further on the list as you develop them,
I'm sure other people will be interested in how you go (definately me).
May even be worth a nice Wiki page outlining your ideas, and how you
accomplished them. I'm sure other people would appreciate it if you
have the time. (see
http://nagoya.apache.org/wiki/apachewiki.cgi?Log4JProjectPages)
cheers,
Paul Smith
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
Re: discreet log types
Posted by Larry Young <ly...@dalmatian.com>.
Paul,
Yes, actually I had already gone down that road as one of my first
solutions before I posted my original message. However, when I considered
that option, I was appending the logging type, which was a problem when
trying to specify packages instead of individual classes. But your
suggestion to put it at the beginning could solve that problem.
I'm not so worried about it being clumsy because I can always hide
it with a wrapper around the front-end if necessary (i.e. create a static
factory-like method). And I would only have to define loggers for the
logging types that my class would be using, not necessarily every one that
is defined, especially since the list needs to be extensible. And it would
also allow me to enable multiple logging types for a single class/package.
I'll have to give this one some more thought! It's not the
cleanest of solutions, but if no one else on the list thinks this would be
a good feature to have, then perhaps this would be the quickest solution
for my situation. Thanks again for your ideas!
--- regards ---
Larry
At 10:51 AM 8/15/03 +1000, you wrote:
>On Fri, 2003-08-15 at 10:52, Larry Young wrote:
> > Paul,
> >
> > Yes, I need to be able to specify which class may display which
> > set of discreet types. For example, I might have "com.*" allowed to
> > display ERROR, but then override that for "com.xyz.MyClass" to display
> only
> > TIMING, "com.abc.def.*" to display METHOD_TRACE & TIMING, and
> > "com.abc.dataaccess.*" to display DB_ACCESS.
>
><snip/>
>
>Yeah, the more I think about it the more I see the issue. Ouch.
>
>Ok, since in each class you like have something like this:
>
>public static final Logger LOG = Logger.getLogger(MyClass.class);
>
>Could you do something like this? (Cumbersome still, but hey, if you
>want Ultimate Configuration it comes with Ultimate complexity usually
>
>public static final DBLogger = Logger.getLogger("DB." +
>MyClass.class.getName() );
>
>public static final TimerLogger= Logger.getLogger("Trace." +
>MyClass.class.getName());
>
>...
>
>That way you will have a Logger for every class and every aspect. You
>can then turn _ALL_ Trace logging by setting the "DB" Logger to whatever
>level, then all the class names inherit from it. You can then also set
>"DB" to INFO, but override with "DB.com.mycompany.MyClass=DEBUG".
>
>Would that help?
>
>cheers,
>
>Paul
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-user-help@jakarta.apache.org
--------------------------
Larry Young
The Dalmatian Group
www.dalmatian.com
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
Re: discreet log types
Posted by Paul Smith <pa...@lawlex.com.au>.
On Fri, 2003-08-15 at 10:52, Larry Young wrote:
> Paul,
>
> Yes, I need to be able to specify which class may display which
> set of discreet types. For example, I might have "com.*" allowed to
> display ERROR, but then override that for "com.xyz.MyClass" to display only
> TIMING, "com.abc.def.*" to display METHOD_TRACE & TIMING, and
> "com.abc.dataaccess.*" to display DB_ACCESS.
<snip/>
Yeah, the more I think about it the more I see the issue. Ouch.
Ok, since in each class you like have something like this:
public static final Logger LOG = Logger.getLogger(MyClass.class);
Could you do something like this? (Cumbersome still, but hey, if you
want Ultimate Configuration it comes with Ultimate complexity usually
public static final DBLogger = Logger.getLogger("DB." +
MyClass.class.getName() );
public static final TimerLogger= Logger.getLogger("Trace." +
MyClass.class.getName());
...
That way you will have a Logger for every class and every aspect. You
can then turn _ALL_ Trace logging by setting the "DB" Logger to whatever
level, then all the class names inherit from it. You can then also set
"DB" to INFO, but override with "DB.com.mycompany.MyClass=DEBUG".
Would that help?
cheers,
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
Re: discreet log types
Posted by Larry Young <ly...@dalmatian.com>.
Paul,
Yes, I need to be able to specify which class may display which
set of discreet types. For example, I might have "com.*" allowed to
display ERROR, but then override that for "com.xyz.MyClass" to display only
TIMING, "com.abc.def.*" to display METHOD_TRACE & TIMING, and
"com.abc.dataaccess.*" to display DB_ACCESS.
I've been looking at the filter solution based on your original
suggestion (thanks!). But if I'm not mistaken, Filters can only be applied
to Appenders, not Loggers. So I would have to define multiple appenders,
one for each logger that I have, or rather one for each logger I explicitly
define in the config file. That would seem to be rather cumbersome. And
using Ceki's solution, each logger is based on the type, so the filter
would still apply to all classes, since there is no class information in
the LogEvent class. I could solve that using MDC, but I am still missing
the critical piece which ties a specific class/package to a list of allowed
logging types.
The trick it seems to me is that I need to define the permitted
logging types per class/package in the config file, just the way logging
levels are defined today, either in conjunction with or as a replacement
for. Ultimately, if I want to be able to enable/disable logging types by a
specific class/package (just like levels are), then I need to build that
association somewhere. I can define it either in the log4j config file, or
in a separate config file (obviously, the fewer config files, the
better!). And that association needs to be maintained in memory at runtime
either with the current logger sitting in the default repository, or in a
new logger class in a separate repository, or in a totally separate global
collection associating loggers to their allowed types.
I am sorry if I'm not explaining myself very well. I have a
pretty clear idea in my head, but perhaps I'm not communicating it very
well. Thanks for all your input!
I am still interested to hear if anyone on the list thinks that
the idea of logging by discreet types is of interest and would be a useful
feature for others out there besides myself. BTW, I'll be out tomorrow, so
I won't be checking my email again until Monday. Have a good weekend!
--- regards ---
Larry
At 07:52 AM 8/15/03 +1000, you wrote:
>On Fri, 2003-08-15 at 07:49, Larry Young wrote:
> > Ceki,
> >
> > That's an interesting way of looking at logger types! But how
> > would that allow me to enable/disable log messages for a particular
> > class? One of the features I need is the ability to specify that a
> > particular class should display a particular type of log message (or
> > possibly more than one). This would appear to only let me set the message
> > type system wide. Did I miss something?
>
>No, you haven't missed anything, it would set the types system wide, and
>allow you to specify the level system wide, but if that was not granular
>enough, can't you specific a particular Filter for your appender? (i.e
>all classes logging to the DB logger, but you filter for a particular
>class).
>
>I'm sure you could write yourself a Filter sub-class very quickly and
>attach it to an Appender via the configuration. You could configure
>this Filter impl with some configuration as to what classes you want to
>see output.
>
>Hope that makes sense.
>
>cheers,
>
>Paul Smith
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-user-help@jakarta.apache.org
--------------------------
Larry Young
The Dalmatian Group
www.dalmatian.com
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
Re: discreet log types
Posted by Paul Smith <pa...@lawlex.com.au>.
On Fri, 2003-08-15 at 07:49, Larry Young wrote:
> Ceki,
>
> That's an interesting way of looking at logger types! But how
> would that allow me to enable/disable log messages for a particular
> class? One of the features I need is the ability to specify that a
> particular class should display a particular type of log message (or
> possibly more than one). This would appear to only let me set the message
> type system wide. Did I miss something?
No, you haven't missed anything, it would set the types system wide, and
allow you to specify the level system wide, but if that was not granular
enough, can't you specific a particular Filter for your appender? (i.e
all classes logging to the DB logger, but you filter for a particular
class).
I'm sure you could write yourself a Filter sub-class very quickly and
attach it to an Appender via the configuration. You could configure
this Filter impl with some configuration as to what classes you want to
see output.
Hope that makes sense.
cheers,
Paul Smith
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
Re: discreet log types
Posted by Larry Young <ly...@dalmatian.com>.
Ceki,
That's an interesting way of looking at logger types! But how
would that allow me to enable/disable log messages for a particular
class? One of the features I need is the ability to specify that a
particular class should display a particular type of log message (or
possibly more than one). This would appear to only let me set the message
type system wide. Did I miss something?
--- regards ---
Larry
At 11:10 PM 8/14/03 +0200, you wrote:
>If it can run, it can also walk!
>
>I think the existing system can be made to closely simulate the behavior
>you describe.
>
>Here is how:
>
>- Set the root logger to the level OFF.
>
>- Name your loggers as "fatal", "error", "timing", "CodeBlock",
>"ControlPoint", "DBAccess", "Info", etc. Set their levels to OFF when you
>create them.
>
>- Whenever you can any of the above loggers, call it with the same
>printing metdod, say info(Object message) of the org.apache.log4j.Logger class.
>
>To enable a "type" set its level to INFO or above. To disable it, set its
>level to DEBUG or lower. Assuming the "type" names do not contain dot
>('.') characters, the "types" will be independent.
>
>Do I need to continue?
>
>At 04:25 PM 7/30/2003 -0700, Larry Young wrote:
>>Hello,
>>
>> I'm looking at creating a logging package for our applications
>> (web & non-web). The reason for yet-another-logger is that I want
>> discreet logging types, not hierarchical levels. I've built this kind
>> of a package before for previous projects, and ended up building the
>> whole thing because I didn't think log4j could do what I wanted (that
>> was several years ago). Now I'm building another one, and looking at
>> the current version of log4j, and having read much of Ceki's book (which
>> I highly recommend!), I'm thinking that there's got to be a way of
>> re-configuring (bending?) log4j to do what I need. I don't think it's
>> that far off.
>>
>> Basically, I want to be able to enable/disable logging for a
>> particular class or package by type, and each type is totally
>> independent of every other type. Some examples of types might
>> be: Fatal, Error, Timing, CodeBlock, ControlPoint, DBAccess, Info,
>> etc. There is no implicit "ordering" between these various types, so
>> "levels" are inappropriate. What I want to be able to do is to turn
>> on/off each type independently, so that I can turn on Timing without
>> having to also turn on Info, or be able to turn on CodeBlock without
>> turning on Error. I also want the users of my package to be able to
>> define additional types and register them with the logger at runtime
>> (via code or xml ???). Oh yeah, I also need to have the logger reload
>> the config file (or some portion of it) on a regular basis so that we
>> can change the enabled types without bouncing the app-server or
>> restarting the application.
>>
>> I was thinking if I tried to tie all my "types" to a single
>> "level", and did something with the log-level filtering to
>> enable/disable by package or class, that would get me close. I'm not
>> sure how I'd tie in the "type". I'd probably have to programatically
>> update the log-level filters with updates to handle config changes at runtime.
>>
>> Thoughts, ideas, concerns??? Any comments are gratefully
>> accepted! :)
>>
>>--- regards ---
>>Larry
>>
>>
>>--------------------------
>>Larry Young
>>The Dalmatian Group
>>www.dalmatian.com
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: log4j-user-help@jakarta.apache.org
>
>--
>Ceki For log4j documentation consider "The complete log4j manual"
> ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-user-help@jakarta.apache.org
--------------------------
Larry Young
The Dalmatian Group
www.dalmatian.com
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
Re: discreet log types
Posted by Ceki Gülcü <ce...@qos.ch>.
If it can run, it can also walk!
I think the existing system can be made to closely simulate the behavior
you describe.
Here is how:
- Set the root logger to the level OFF.
- Name your loggers as "fatal", "error", "timing", "CodeBlock",
"ControlPoint", "DBAccess", "Info", etc. Set their levels to OFF when you
create them.
- Whenever you can any of the above loggers, call it with the same printing
metdod, say info(Object message) of the org.apache.log4j.Logger class.
To enable a "type" set its level to INFO or above. To disable it, set its
level to DEBUG or lower. Assuming the "type" names do not contain dot ('.')
characters, the "types" will be independent.
Do I need to continue?
At 04:25 PM 7/30/2003 -0700, Larry Young wrote:
>Hello,
>
> I'm looking at creating a logging package for our applications
> (web & non-web). The reason for yet-another-logger is that I want
> discreet logging types, not hierarchical levels. I've built this kind of
> a package before for previous projects, and ended up building the whole
> thing because I didn't think log4j could do what I wanted (that was
> several years ago). Now I'm building another one, and looking at the
> current version of log4j, and having read much of Ceki's book (which I
> highly recommend!), I'm thinking that there's got to be a way of
> re-configuring (bending?) log4j to do what I need. I don't think it's
> that far off.
>
> Basically, I want to be able to enable/disable logging for a
> particular class or package by type, and each type is totally independent
> of every other type. Some examples of types might be: Fatal, Error,
> Timing, CodeBlock, ControlPoint, DBAccess, Info, etc. There is no
> implicit "ordering" between these various types, so "levels" are
> inappropriate. What I want to be able to do is to turn on/off each type
> independently, so that I can turn on Timing without having to also turn
> on Info, or be able to turn on CodeBlock without turning on Error. I
> also want the users of my package to be able to define additional types
> and register them with the logger at runtime (via code or xml ???). Oh
> yeah, I also need to have the logger reload the config file (or some
> portion of it) on a regular basis so that we can change the enabled types
> without bouncing the app-server or restarting the application.
>
> I was thinking if I tried to tie all my "types" to a single
> "level", and did something with the log-level filtering to enable/disable
> by package or class, that would get me close. I'm not sure how I'd tie
> in the "type". I'd probably have to programatically update the log-level
> filters with updates to handle config changes at runtime.
>
> Thoughts, ideas, concerns??? Any comments are gratefully
> accepted! :)
>
>--- regards ---
>Larry
>
>
>--------------------------
>Larry Young
>The Dalmatian Group
>www.dalmatian.com
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-user-help@jakarta.apache.org
>
--
Ceki For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org