[prev in list] [next in list] [prev in thread] [next in thread] 

List:       java-apache-framework
Subject:    Re: Inheritance of log priorities?
From:       Peter Donald <donaldp () apache ! org>
Date:       2000-11-22 1:06:09
[Download RAW message or body]

At 10:29  22/11/00 +1030, you wrote:
>> LogKit.setPriority( Category category, Priority.Enum priority );
>> 
>> and it will set the category and all child categories to priority. Not sure
>> - this is more in line with the way the Java Loggign extention works - what
>> do you think ?
>
>How is this CPU intensive?  A category chain is not that long the
>worst one I have thought of is
>
><layer><level><FQN>
>
>So this allows me to set logging up for the logical layer of the
>component, with variations at different levels within the logical
>layer and I also have fine grain control at the package level.  I
>think there is a suggestion like this at the log4j site.
>
>So for a real world example:
>
>application.myapp.somelevel.org.apache.avalon.somepackage.someclass

right.

When I initially designing the log package I was deploying on a machine
with high CPU usage already (Servlets with a 90% CPU usage) so I need to
trim the fat in all places ;)

>At worst this memory consumption, if you instantiate loggers for all
>categories as is done currently.  And logger doesn't look like it has
>a huge memory footprint.  I can't see a way to decrease this as you
>must instantiate a logger when requested for a category.  This logger
>is coupled to the category so it can't be shared with other
>categories.  Each category must also be instantiated and there isn't
>anything other than name to share.  Neither of these classes is huge
>so trying to create a lzaily evaluated class or a flyweight seems
>pointless.  Memory will be consumed for a Logger and a Category every
>time a Logger is requested.  Can't see any way around this.

memory was never a problem - especially considering there was rarely more
than 40-50 loggers even in the most complex of applications.

>> So there will soon be no difference technically. I just don't like the
>> baggage that log4j collected and the extra CPU time was a killer when I
>> first started using it. I would love to work with Ceki to get best bits
>> together but it is too much of a risk to make the move without guarentees
>> and with the new Java Logging Framework Standard extention coming up I
>> suspect both these toolkits will need mods then. So - if log4j gets to
>> Apache in time then I will switch otherwise there will be two different
>> toolkits ;)
>
>I saw somewhere a discussion on the JSR on logging and that log4j
>already provides the functionality and more and that the JSR is likely
>to out of date before its released.

I agree - but a lot of people don't ;)

>> >Is it not easier to contribute to log4j the modifications needed to
>> >make it fit into Avalon?
>> 
>> sorta - it would be easy to mod log4j but it would break backward
>> compatability with previous log4js which I don't think would be acceptable.
>> I was hoping to do it when it moves to Apache because backward
>> compatability would break then anyways. Of course this depends on when it
>> occurs .. if it doesn't happen soon enough I will just keep adding to this
>> framework.
>
>I dont see how it would break backward compatibility.  Its an ugly
>interim solution, Categories would just delegate to Logger to do
>logging.
>
>I'm not sure where else the breakage occurs.  Perhaps in lookup in
>which case Category would delegate to LogKit.

Well last time I looked at Log4j it kind of assumed a hardwiring and did
not allow easy dynamic reconfiguration of logtargets. To enable this would
require a lot of rewiring underneath. So anything that extended log4j would
require rewriting. There is also a lot of other assumptions (like static
NDCs that are not thread inheritable) that would be difficult to change
without breaking backwards compatability.

>Deprecate the old way and one day remove it.
>
>btw why does moving log4j to apache allow breaking of backwards
>compatibility?

It already involves changing packages (ie to org.apache.log4j) so a few
more changes shouldn't be a problem ;)


Cheers,

Pete

*------------------------------------------------------*
| Despite your efforts to be a romantic hero, you will |
| gradually evolve into a postmodern plot device.      |
*------------------------------------------------------*



------------------------------------------------------------
To subscribe:    java-apache-framework-on@list.working-dogs.com
To unsubscribe:  java-apache-framework-off@list.working-dogs.com
Problems?:       jon@working-dogs.com

[prev in list] [next in list] [prev in thread] [next in thread]