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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
