commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@optonline.net>
Subject Re: [logging] Need interface...
Date Wed, 03 Apr 2002 19:03:07 GMT
On 4/3/02 1:54 PM, "Jon Scott Stevens" <jon@latchkey.com> wrote:

> on 4/3/02 10:49 AM, "Geir Magnusson Jr." <geirm@optonline.net> wrote:
> 
>> On 4/3/02 1:12 PM, "Jon Scott Stevens" <jon@latchkey.com> wrote:
>> 
>>> on 4/3/02 10:09 AM, "Jon Scott Stevens" <jon@latchkey.com> wrote:
>>> 
>>>> Now, if the parent instantiates MyComponent and forgets to call
>>>> enableLogging() *before* myMethod() is called, an NPE will be thrown and
it
>>>> will not be clear as to why that NPE was thrown unless you go and look at
>>>> the source code. There is no open coding contract that says that
>>>> enableLogging() needs to be called first.
>>> 
>>> I should also add that I don't like the fact that a parent is required.
>>> 
>> 
>> I'm not being clear - it doesn't *require* anything.  If the method isn't
>> called by the 'parent', it doesn't log.  Very simple.
> 
> Look at the example code I posted. It was:
> 
> class
> {
> }
> 
> Who is going to be able to instantiate that class outside of the package?

No one - that code wouldn't even compile because myMethod() didn't have a
return type - so I figured you were illustrating the point about the logger.
NPE...

> 
>> The alternative is to invent a new framework and write the components to
>> work with it explicitly - namely the road they were going down in
>> vel-tools...
> 
> No. You simply make a dependency on commons-logging.

Why?  What if they aren't using it?  To use my DateFooTool, you have to
switch your entire logging infrastructure, rather than just wrap the Log
interface around what you have?

> 
>>> If a parent is required, then it requires a framework to support the
>>> children (ie: that is what a parent really is).
>>> 
>>> Sure, sometimes frameworks are appropriate, but I don't think they are
>>> necessary for Velocity tools which are just objects stuck in the context...
>> 
>> There is no framework required here :
>> 
>> if ( the instantiator of the class decides to look for LogUser
>>      && the instantiator has a logger impl that implements Log interface)
>> {
>>   call setCommonsLog() so the component can log
>> }
>> else
>> {
>>  do nothing
>> }
>> 
>> I am sorry if I'm not clear.  My suggestion has nothing to do with a
>> framework - the idea of logging is optional for what I am thinking of...
> 
> Sorry if I'm not clear, but I don't think you read the example code I
> posted.

Ok - try again - what's the problem?

-- 
Geir Magnusson Jr.                                     geirm@optonline.net
System and Software Consulting
Java : the speed of Smalltalk with the simple elegance of C++... 


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message