Re: Logging, IoC and Avalon

[Stephen McConnell <mc...@apache.org>]

Leo Simons wrote:

> Stephen McConnell wrote:
>
>> Finally, onto some Avalon concerns.
>>
>> Two points:
>>
>> (a) configuration exceptions would be more useful if they contained
>> the offending fragment
>
>
> indeed. Howard's HiveMind solves this beautifully: it reports the 
> filename and line number for any config error. I expect its trivial in 
> hivemind to expand on that information to get some surrounding context.


I suggest we add the following to ConfigurationException

    final Configuration m_fragment;

    public ConfigurationException( String message, Configuration fragment )
    {
        m_fragment = fragment;
    }

With this little addition, exception handling utilities can do a lot 
more to report and present information linked to a configuration related 
error. Unless anyone objects I'll go ahead and update framework and test 
things out.

>
>> (b) better specs are needed about component/container seperation
>> of responsibilities (e.g. who handled error reporting)
>
>
> specs? Why specs? How about some general guidelines? 


Because guidelines without specs are for wimps.


Ok - guideline are helpful - but only when you have concrete knowledge 
and that's where a spec comes into play.  The spec states what a 
container is obliged to do with respect to something like a component 
lifecycle processing exception.  A guideline can drawn upon this 
knowledge and present recommendations to developers as to how they can 
best manage their interaction on the the component/container boundary.

>
>
> "Log then rethrow at any containment boundary"
>
> A server logs details of an internal exception, then sends on less 
> detailed information to the client. A servlet applications logs 
> details of an internal exception, then sends on less detailed 
> information to the servlet container.
>
> That's the general rule. 


Why?

The container can provide comprehensive error management - why push this 
onto the component?

> However, it makes sense to offload log management towards the 
> container in an IoC application. If/when you do that, you should trust 
> the container to do logging properly for you. 


Which is where the notion of a specification comes into play.

>
>
> More concretely, anytime you throw an exception from any lifecycle 
> method that is an subclass of CascadingException and/or 
> CascadingThrowable, 


In Merlin its a class with a getCause() method.
(i.e. just a touch less locked in on Avalon APIs).

> and you provide the "cause" of the exception, do not log that cause 
> seperately, it will be done for you. If you do not provide the "cause" 
> when rethrowing, *do* log the cause but not the rest:
>
>     catch( SomeException se )
>     {
>         getLog().error( "whoops", se );
>         throw new ServiceException( "some.thing" );
>     }
> or
>     catch( SomeException se )
>     {
>         throw new ServiceException( "some.thing", se );
>     }
> not
>     // will print a stacktrace twice with any worthwile
>     // logger
>     catch( SomeException se )
>     {
>         getLog().error( "whoops", se );
>         throw new ServiceException( "some.thing", se );
>     }
> nor
>     // will print a stacktrace trice with any worthwile
>     // logger
>     catch( SomeException se )
>     {
>         getLog().error( "whoops", se );
>         se.printStackTrace();
>         throw new ServiceException( "some.thing", se );
>     }


Yep.

>
> with non-lifecycle methods, things are a bit different. You *may* be 
> crossing an application boundary; depends on your component 
> granularity. If you have
>
> interface RequestHandler
> {
>     Response handle( Request request )
>         throws RequestException;
> }
>
> I will bet you that you will often not want to return the cause of the 
> RequestException. So here you always have
>
>     catch( SomeException se )
>     {
>         // record specifics with this component
>         getLog().error( "whoops", se );
>
>         // rethrow a more generic exception; don't give
>         // clients information about the internals of the
>         // implementation
>         throw new RequestException( 500 );
>     }


Which suggests that the component is taking on some management decisions 
- which happens to be the case in the James example (in fact James is 
doing component deployment itself inside the deployment by the hosting 
container which complicates things somewhat).  But, something worth 
taking into consideration is the potential for category management.  For 
example in Merlin exception report is provided under the kernel logging 
categrogoy because its a deployment failure.  An alternative approach 
couild be log this information under the logging category assigned to 
the compoent type manager (as distinct from the channel that the James 
component was logging to).  All this means is that we have a lot of 
scope with respect to where we place information and that this can be 
translated into useful information using support tools.

>
> All this is hardly avalon-specific. There's several books that deal 
> with the generic issue. I believe Ceki wrote a nice one (that I 
> haven't read though).
>
> all IMHO.
>
> cheers! 


Steve.

>
>
> - LSD
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net

Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

Re: Logging, IoC and Avalon

[Leo Simons <le...@apache.org>]

Stephen McConnell wrote:
> I suggest we add the following to ConfigurationException
> 
>    final Configuration m_fragment;
> 
>    public ConfigurationException( String message, Configuration fragment )
>    {
>        m_fragment = fragment;
>    }

not as nice as the way HiveMind handles it; but perhaps a good start. I 
know Berin is also interested in setting something like this up.

>>> (b) better specs are needed about component/container seperation
>>> of responsibilities (e.g. who handled error reporting)
>>
>> specs? Why specs? How about some general guidelines? 
> 
> Because guidelines without specs are for wimps.
> 
> Ok - guideline are helpful - but only when you have concrete knowledge 
> and that's where a spec comes into play.  The spec states what a 
> container is obliged to do with respect to something like a component 
> lifecycle processing exception.  A guideline can drawn upon this 
> knowledge and present recommendations to developers as to how they can 
> best manage their interaction on the the component/container boundary.

My guess is that it is wholly impossible to write (logging) specs for 
the diverse set of IoC containers that exist in the world today, so it 
is also impossible to state "do your logging <this/> way and it will 
work the best". You can only do that for a particular container, or 
perhaps a few.

I would say, write your specs for merlin, and make sure they follow the 
generally accepted standard practices :D

>> interface RequestHandler
>> {
>>     Response handle( Request request )
>>         throws RequestException;
>> }
>>
>> I will bet you that you will often not want to return the cause of the 
>> RequestException. So here you always have
>>
>>     catch( SomeException se )
>>     {
>>         // record specifics with this component
>>         getLog().error( "whoops", se );
>>
>>         // rethrow a more generic exception; don't give
>>         // clients information about the internals of the
>>         // implementation
>>         throw new RequestException( 500 );
>>     }
> 
> Which suggests that the component is taking on some management decisions 
> - which happens to be the case in the James example (in fact James is 
> doing component deployment itself inside the deployment by the hosting 
> container which complicates things somewhat).  But, something worth 
> taking into consideration is the potential for category management.  For 
> example in Merlin exception report is provided under the kernel logging 
> categrogoy because its a deployment failure.

there's various approaches available, but deciding which one is the best 
in all cases is, I think, very difficult. If you have a system comprised 
of a 10 components it makes sense to have a-category-per-component. If 
you have 300 you need to aggregrate and categorize subsets. Hierarchical 
models come into mind again. Regardless,

      catch( SomeException se )
      {
          // record specifics with this component
          getLog().error( "whoops", se );
          throw new RequestException( 500 );
      }

is so common in real life that IMO a container should be well-geared to 
support it.

cheers!

- LSD



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org