Re: [logkit] Category setting

[Charles Benett <ch...@benett1.demon.co.uk>]

-1 (temp) Can you hold off for a few days?

I'm not happy with the way James logs (using logkit). At the moment I
don't know if that is because (1) I don't understand logkit (2) james
isn't implementing logkit properly or (3) there are issues with logkit.

This isn't helped by a commit of cornerstone in James with a broken
scheduler (so james cvs isn't running at the moment). Once that is fixed
(and package names changed) I'll try to explain what I don't like about
its logging - but I think its the way it currently handles categories.

Charles

Peter Donald wrote:
> 
> If no one -1s in next day or two I will do the following. After that I
> think the only two things code-wise before release to look at is
> excalibur.thread and possibly excalibur.pool (Berin how does it look?). Any
> other knits code-wise???
> 
> At 02:25  26/4/01 +1000, you wrote:
> >Hi,
> >
> >Before we go beta we should decide on whether or not we update Category
> >setting. Currently when you set the priority of a category it sets just
> >that category. However when you set the logtargets it sets it for the
> >hierarchy (minus those who are explicitly set). For example consider the
> >following categories
> >
> >a.1.p
> >a.1.q
> >a.1.r
> >a.2.p
> >a.3.p
> >
> >If I was to set the log target of to a file "/var/log/a" then all of the
> >targets would write to this one target. If you also set the log target of
> >a.1 to "/var/log/1" then all of a.1.* would write to this file while the
> >others would write to the original file. So the algorithm is basically "If
> >log target is not set get parent to write it out".
> >
> >Categories in logkit don't work this way (though in most other systems such
> >as jSyslog/Log4j/protomatter/Logging JSR they do). The original reason was
> >because I didn't have the time to do it right. I could have hacked it
> >together (much the same way the other toolkits do) but that would kill
> >performance (they effectively lookup parents priority on each access). By
> >the time I had enough time to fix it to many peeps were using the kit and
> >relying on functionality. As I convinced everyone to move to Log4j now
> >would be the time to do it if ever (ie before beta).
> >
> >Simultaneously I would also merge the "Category" object into Logger objects
> >and possibly add pluggable ErrorHandlers (if time was sufficient). The
> >effects this would have on the "client" use is the following
> >
> >getLogger().getCategory().getPriority() -=> getLogger().getPriority()
> >getLogger().getCategory().getName() -=> getLogger().getName()
> >getLogger().getCategory().setPriority( priority ) -=>
> >LogKit.setPriority( getLogger().getName(), priority )
> >
> >and the SPI would also change both semantics (as given above) and interface
> >(merge getCategory/getLogger).
> >
> >Thoughts?
> >
> >Cheers,
> >
> >Pete
> >
> >*-----------------------------------------------------*
> >| "Faced with the choice between changing one's mind, |
> >| and proving that there is no need to do so - almost |
> >| everyone gets busy on the proof."                   |
> >|              - John Kenneth Galbraith               |
> >*-----------------------------------------------------*
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
> >
> >
> Cheers,
> 
> Pete
> 
> *-----------------------------------------------------*
> | "Faced with the choice between changing one's mind, |
> | and proving that there is no need to do so - almost |
> | everyone gets busy on the proof."                   |
> |              - John Kenneth Galbraith               |
> *-----------------------------------------------------*
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org