Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: 64.74.244.71 is neither permitted nor
 denied by domain of geir@pobox.com)
Message-ID: <447C92DC.9070909@pobox.com>
Date: Tue, 30 May 2006 11:45:48 -0700
From: Geir Magnusson Jr <geir@pobox.com>
Reply-To: geir@pobox.com
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib] logging from within our implementation
References: <447C6E8B.8020202@pobox.com> <447C8D4B.3060901@gmail.com>
In-Reply-To: <447C8D4B.3060901@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Tim Ellison wrote:
> Geir Magnusson Jr wrote:
>> Seems like there is an important issue here, but the discussion can't
>> seem to escape out of the thicket of the example.
>>
>> 1) Should we allow any logging from within the classlibrary?
> 
> Just in case there was any doubt from my earlier postings...
> 
> I think we should not be explicitly logging debug info as part of our
> class library implementation.

In any form?

>> 2) How should we do it?
>>
>> There are a bunch of ways for the second question...  using j.u.l, using
>>  IOC and injecting our own logging target to reduce dependencies and
>> make people think before logging, using aspects?
> 
> Both j.u.l and IoC would require code in the implementation to perform
> the logging actions (or check the guard).  Putting this logic throughout
> the class library will IMHO result in module coupling, code bloat and
> overall performance degradation (or no logging!).

Right - that's why I was thinking of the latter.  Something that would 
have no runtime overhead, yet allow us to capture more information other 
than just execution path and stack values :)
> 
> Adding logging statements is expecting the class library developer to
> decide /a priori/ what debug|trace info is useful to the person trying
> to resolve a problem.  Existing debug|trace tools work with the runtime
> to figure out the pertinent information as you are interested in it.
> (The only caveat being 'flight data recorder' type trace where the trace
> points are typically very low overhead and always on).
> 
>> Comments?  We probably should try to get to a conclusion in general...
> 
> The logging info being proposed is developer-oriented.  I hope that
> people are not expecting our users to understand our developer trace
> info -- we, as developers, have better tools than printf to figure out
> what is happening.

I have to admit that I don't agree w/ "better" as a universally general 
statement, as debug statements can include information provided by the 
developer not immediately obvious.

Is there some kind of aspect framework we can use?  Then for 
develeopers, they have to implicitly do something to get the stuff to 
come out, it's not a runtime cost for anyone else, and the stuff stays 
in the codebase for use later?

geir

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org