Re: discreet log types
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: discreet log types
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ceki For log4j documentation consider The complete log4j manual
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: discreet log types
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ceki For log4j documentation consider The complete log4j manual
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Larry Young
The Dalmatian Group
www.dalmatian.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: discreet log types
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: discreet log types
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Larry Young The Dalmatian Group www.dalmatian.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: discreet log types
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: discreet log types
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: discreet log types
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
