AT> ConfigurationException ... make sure this exception alone
AT> carries enough info to trace the problem, e.g. it has
AT> * Configuration.getLocation() including full path name and line
AT> number
AT> * the id and probably type of the offending component
AT> (that's what I'm thinking about - probably subclassing
AT> ConfigurationException and adding the info there, or
AT> putting it somehow into message, or changing the
AT> ConfigurationException itself, or changing
AT> CascadingException - you see I'm not afraid to touch
AT> the most sacred things :-)
Have forgotten one more option, probably one of the easiest:
we wrap the ConfigurationException (or a ServiceException
for that case) into something like
o.a.a.fotress.ActivationException extends CascadingException
{
ActivationExcption( String id, Throwable t ) { super( id, t ); }
}
Goes without saying that for this exception we will produce no
trace either.
So this is what the user will get in log:
ActivationException: 'cool-component' caused by
ConfigurationException: badly broken config: file:/D:/conf/super.xconf:27
or at our desire we may completely make the logging
of ActivationException transparent:
Failed to acitiavate component 'cool-component': ConfiguratonException: badly
broken config: file:/D:/conf/super.xconf:27
(we still have two nested excptions, just the code is clever enough to
merge them into one line)
-Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
