on 4/3/02 10:49 AM, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote:
> On 4/3/02 1:12 PM, "Jon Scott Stevens" <[EMAIL PROTECTED]> wrote:
>
>> on 4/3/02 10:09 AM, "Jon Scott Stevens" <[EMAIL PROTECTED]> 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?
> 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.
>> 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.
-jon
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
