avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [logkit] Category setting
Date Mon, 30 Apr 2001 12:48:35 GMT
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


Mime
View raw message