You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2002/06/15 17:12:55 UTC

[A5] Logger Package

I find the logger package to be pretty decent.  However, there are a few
things
to consider:

1) Instead of having many different logging abstractions, what about
using
   Commons Logging (ducks and hides)?
2) If we maintain our own, what about a "TRACE" logging level.  It is
useful
   debugging information that is not necessary for all debugging
excercises.
   Some bugs are only found by tracing through, so a message when
entering
   a method or exiting a method can be helpful.  Esp. if your Java
debugger
   is effectively broken (happens more often than I care to mention).


"They that give up essential liberty to obtain a little temporary safety
 deserve neither liberty nor safety."
                - Benjamin Franklin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [A5] Logger Package

Posted by Peter Royal <pr...@apache.org>.
On Saturday 15 June 2002 11:12 am, Berin Loritsch wrote:
> 1) Instead of having many different logging abstractions, what about
> using
>    Commons Logging (ducks and hides)?

+1
Code sharing is good. Especially from projects all under the same umbrella.

We will probably need to bring some of our features back to commons though. 
>From browsing their javadocs it appears that there is no way to get a child 
logger from a given logger. The retrieval methods for loggers (at least in 
the javadoc examples) is a static method on a factory which isn't very 
IoC-ish.
-pete

-- 
peter royal -> proyal@apache.org

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [A5] Logger Package

Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote:
> I find the logger package to be pretty decent.  However, there are a few
> things
> to consider:
> 
> 1) Instead of having many different logging abstractions, what about
> using
>    Commons Logging (ducks and hides)?

+1

One thing is the logger, one thing is giving the logger to the user.
We would still have a IoC method to give the logger to the Component, 
while giving in fact a commons-logging thing; then put logkit as an 
implementation of commons logging.

On the commons list, Geir has shown great interest in having an 
alternative method of getting a logger as Avalon does; if we use 
commons-logging directly, he would have a solution easy at hand.

I'm sure that we should concentrate more on interfaces and facades and 
leave implementation to others.

So I'm (sayind it again) really +1 for using commons-logging as a Logger.

> 2) If we maintain our own, what about a "TRACE" logging level.  It is
> useful
>    debugging information that is not necessary for all debugging
> excercises.
>    Some bugs are only found by tracing through, so a message when
> entering
>    a method or exiting a method can be helpful.  Esp. if your Java
> debugger
>    is effectively broken (happens more often than I care to mention).
> 

-0 No need here, but anyway if we use commons loogging... ;-)

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [A5] Logger Package

Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote:
 >
> eh? You mean you want to put trace() statements in your code for the
> lack of a good debugger?
> 
> -1. Get a good debugger, I'd say. Tracing is a separate concern from
> logging.

Good point.

I think that many projects use logging while instead they are doing tracing.

FOP uses avalon logging, but it's just a way of tracing AFAIK.
I made POI use commons-logging, but it came clear now that it's not 
correct; it has been a PITA to have a package like POI have a dependency 
on logging, so I just made my fast tracing classes that can goto null, 
system.out or commons-logging, but don't need the package.

Shall we put a simple tracing package?

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: [A5] Logger Package

Posted by Berin Loritsch <bl...@apache.org>.
> From: Leo Simons [mailto:leosimons@apache.org] 
> 
> eh? You mean you want to put trace() statements in your code 
> for the lack of a good debugger?
> 
> -1. Get a good debugger, I'd say. Tracing is a separate 
> concern from logging.


I would if every JDK release didn't break the last one.
Seriously, I can't stand java.lang.Verify errors killing
my ability to step through.

The next best thing is trace() level logging.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [A5] Logger Package

Posted by Peter Royal <pr...@apache.org>.
On Sunday 16 June 2002 10:56 am, Leo Sutic wrote:
> > From: Leo Simons [mailto:leosimons@apache.org]
> >
> > -1. Get a good debugger, I'd say. Tracing is a separate
> > concern from logging.
>
> I disagree and put in a +1. Sometimes you can only get the data you
> need by running the system in production mode and trying to grab as much
> as you can from the logs. (The debugger changes the execution
> environment
> too much.)
>
> If Robert Mouat's idea - use dynamic proxies for the tracing - works
> we can get this basically for free.

I'm +1 on the TRACE implemented via dynamic proxies. I do have (imho) a good 
debugger (IDEA, anything better?) but sometimes its impratical to attach the 
debugger to a running system a few hundred miles away.
-pete

-- 
peter royal -> proyal@apache.org

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: [A5] Logger Package

Posted by Leo Simons <le...@apache.org>.
> > From: Leo Simons [mailto:leosimons@apache.org] 
> > 
> > -1. Get a good debugger, I'd say. Tracing is a separate 
> > concern from logging.
> 
> I disagree and put in a +1. Sometimes you can only get the data you 
> need by running the system in production mode and trying to grab as much
> as you can from the logs. (The debugger changes the execution
> environment
> too much.)
> 
> If Robert Mouat's idea - use dynamic proxies for the tracing - works
> we can get this basically for free.

+1 on that one, too. I'm perfectly fine with debugging "transparant" for
components, especially when dynamic. I thought the proposal here was
about having trace() inside component methods (which should be
discouraged, as that'll be far from free).

cheers,

- Leo



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: [A5] Logger Package

Posted by Leo Sutic <le...@inspireinfrastructure.com>.

> From: Leo Simons [mailto:leosimons@apache.org] 
> 
> -1. Get a good debugger, I'd say. Tracing is a separate 
> concern from logging.

I disagree and put in a +1. Sometimes you can only get the data you 
need by running the system in production mode and trying to grab as much
as you can from the logs. (The debugger changes the execution
environment
too much.)

If Robert Mouat's idea - use dynamic proxies for the tracing - works
we can get this basically for free.

/LS





--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [A5] Logger Package

Posted by Leo Simons <le...@apache.org>.
On Sat, 2002-06-15 at 17:12, Berin Loritsch wrote:
> I find the logger package to be pretty decent.  However, there are a few
> things
> to consider:
> 
> 1) Instead of having many different logging abstractions, what about
> using
>    Commons Logging (ducks and hides)?

+0. Would be cool but what we have is extremely stable so I have no
*need* to change.

Also, dependency would be like this

Avalon LogKit <--loose-- commons logging <-- Avalon Framework

Which is cool, just something to keep in mind.

> 2) If we maintain our own, what about a "TRACE" logging level.  It is
> useful
>    debugging information that is not necessary for all debugging
> excercises.
>    Some bugs are only found by tracing through, so a message when
> entering
>    a method or exiting a method can be helpful.  Esp. if your Java
> debugger
>    is effectively broken (happens more often than I care to mention).

eh? You mean you want to put trace() statements in your code for the
lack of a good debugger?

-1. Get a good debugger, I'd say. Tracing is a separate concern from
logging.

- Leo



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [A5] Logger Package

Posted by Stephen McConnell <mc...@osm.net>.

Berin Loritsch wrote:
> I find the logger package to be pretty decent.  However, there are a few
> things to consider:
> 
> 1) Instead of having many different logging abstractions, what about
>    using Commons Logging (ducks and hides)?
> 2) If we maintain our own, what about a "TRACE" logging level.  It is
>    useful debugging information that is not necessary for all 
 >    debugging excercises.
>    Some bugs are only found by tracing through, so a message when
>    entering a method or exiting a method can be helpful.  Esp. if your 
 >    Java debugger is effectively broken (happens more often than I
>    care to mention).
> 

I am +1 on the addition of a trace level.
(based on client demands).

There is also an issue concerning logging catagories.  Catagories (child 
loggers) are maintained as strong references - it would be very 
desirable for catagories to be handled as weak references enabling 
better garbage collection in situations where large numbers of 
catagories are dynamcially created).

Cheers, Steve.


-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [A5] Logger Package

Posted by Eung-ju Park <co...@apache.org>.
1) -1 : avalon abstraction is better than commons-logging.
2) +0

----- Original Message -----
From: "Berin Loritsch" <bl...@apache.org>
To: "'Avalon Developers List'" <av...@jakarta.apache.org>
Sent: Sunday, June 16, 2002 12:12 AM
Subject: [A5] Logger Package


I find the logger package to be pretty decent.  However, there are a few
things
to consider:

1) Instead of having many different logging abstractions, what about
using
   Commons Logging (ducks and hides)?
2) If we maintain our own, what about a "TRACE" logging level.  It is
useful
   debugging information that is not necessary for all debugging
excercises.
   Some bugs are only found by tracing through, so a message when
entering
   a method or exiting a method can be helpful.  Esp. if your Java
debugger
   is effectively broken (happens more often than I care to mention).


"They that give up essential liberty to obtain a little temporary safety
 deserve neither liberty nor safety."
                - Benjamin Franklin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [A5] Logger Package

Posted by Robert Mouat <ro...@mouat.net>.
Berin Loritsch wrote:

> 2) If we maintain our own, what about a "TRACE" logging level.  It is useful
>    debugging information that is not necessary for all debugging excercises.
>    Some bugs are only found by tracing through, so a message when entering
>    a method or exiting a method can be helpful.  Esp. if your Java debugger
>    is effectively broken (happens more often than I care to mention).

this could perhaps be done by the container+ComponentManager...

a dynamic proxy could be created that logged all component method calls.  
This has several advantages:

 - no need to write lots of trace("Entering someMethod()"); calls.
 - you can add tracing to compiled code.
 - you can send the log messages to a different logger without adding the
   extra logging level
 - no need to write lots of trace("Leaving someMethod()"); calls.

possible disadvantages:

 - only traces calls at the component level, wont trace calls within the
   component.
 - only works if the container supports it.

Robert.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>