You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Donald <do...@apache.org> on 2001/04/26 06:25:49 UTC

[logkit] Category setting

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


Re: [logkit] Category setting

Posted by 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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org


Re: [logkit] Category setting

Posted by 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


Re: [logkit] Category setting

Posted by Charles Benett <ch...@benett1.demon.co.uk>.

Peter Donald wrote:
> 
> Hi,
> 
> Charles:
> you looking closely enough at james logging yet to coment on this change?

I think it should be fine: +1
Charles

> 
> Everyone else:
> 
> Now that avalon is going beta I am spending a lot of my time converting
> things to avalon (13 projects totalling 1500 files to go ;]) ... in
> meantime anything left for me to do pre-release? Or are we all set?
> 
> 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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org


Re: [logkit] Category setting

Posted by Peter Donald <do...@apache.org>.
Hi,

Charles:
you looking closely enough at james logging yet to coment on this change?

Everyone else:

Now that avalon is going beta I am spending a lot of my time converting
things to avalon (13 projects totalling 1500 files to go ;]) ... in
meantime anything left for me to do pre-release? Or are we all set?


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


Re: [logkit] Category setting

Posted by Peter Donald <do...@apache.org>.
At 10:08  30/4/01 -0400, Berin Loritsch wrote:
>Peter Donald wrote:
>> 
>> At 08:48  30/4/01 -0400, Berin Loritsch wrote:
>> >I will test excalibur.component with DefaultPool and
>> SoftResourceLimittingPool.
>> >If both work as expected, I will make it use the
SoftResourceLimittingPool.
>> >I will test excalibur.datasource with HardResourceLimittingPool, and if it
>> >works, I will use that.  That way, we don't have two implementations of
the
>> >pooling code that are reimplimentations of what we should be using anyway.
>> 
>> sounds good.
>> 
>> >As far as excalibur.thread is concerned, how should we test that?
>> 
>> Second thoughts - I don't have cycles to do what I wanted .. how about we
>> move it to the whiteboard/scratchpad directory for release and then
>> remigrate it back post release?
>
>Full release or beta 1?  I would vote after Full Release...

+1 for full release

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


Re: [logkit] Category setting

Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> 
> At 08:48  30/4/01 -0400, Berin Loritsch wrote:
> >I will test excalibur.component with DefaultPool and
> SoftResourceLimittingPool.
> >If both work as expected, I will make it use the SoftResourceLimittingPool.
> >I will test excalibur.datasource with HardResourceLimittingPool, and if it
> >works, I will use that.  That way, we don't have two implementations of the
> >pooling code that are reimplimentations of what we should be using anyway.
> 
> sounds good.
> 
> >As far as excalibur.thread is concerned, how should we test that?
> 
> Second thoughts - I don't have cycles to do what I wanted .. how about we
> move it to the whiteboard/scratchpad directory for release and then
> remigrate it back post release?

Full release or beta 1?  I would vote after Full Release...

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


Re: [logkit] Category setting

Posted by Peter Donald <do...@apache.org>.
At 08:48  30/4/01 -0400, Berin Loritsch wrote:
>I will test excalibur.component with DefaultPool and
SoftResourceLimittingPool.
>If both work as expected, I will make it use the SoftResourceLimittingPool.
>I will test excalibur.datasource with HardResourceLimittingPool, and if it
>works, I will use that.  That way, we don't have two implementations of the
>pooling code that are reimplimentations of what we should be using anyway.

sounds good.

>As far as excalibur.thread is concerned, how should we test that?

Second thoughts - I don't have cycles to do what I wanted .. how about we
move it to the whiteboard/scratchpad directory for release and then
remigrate it back post release?

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


Re: [logkit] Category setting

Posted by Berin Loritsch <bl...@apache.org>.
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???

As far as your Category stuff is concerned, it all looks good.

I took a look at excalibur.pool and committed changes that make it coincide
with the other pool implementations that I have.  Unfortunately, I haven't
had time to play with them yet.


I will test excalibur.component with DefaultPool and SoftResourceLimittingPool.
If both work as expected, I will make it use the SoftResourceLimittingPool.
I will test excalibur.datasource with HardResourceLimittingPool, and if it
works, I will use that.  That way, we don't have two implementations of the
pooling code that are reimplimentations of what we should be using anyway.

As far as excalibur.thread is concerned, how should we test that?

> 
> 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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org


Re: [logkit] Category setting

Posted by Peter Donald <do...@apache.org>.
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