Hi, Leif, Berin and all!
Looks like the question of minimizing the stack traces
is still on the table. To me it splits into the following
sub-areas:
1) AbstractContainer throws a CompositeException from
initialize()
Good.
AbstractContainer can be taught not to log
anything itself. (Or log with level debug).
Then we would be able to allow the invoker
to do the logging.
The invoker may safely omit stack traces
for certain "safe" exceptions
ConfigurationException
ServiceException
ContextException
and print only the message.
2)
But for this to be nice, it would be really
good for every exception in CompositeException
to carry info on what component caused the
failure.
What should this info be? The 'id' should be
enough. Ok?
How to pass id along with exception?
3)
Pack the info into the CompositeException
it would be very easy to provide a
public String[] getIds();
method that would return an array of ids.
Very easy, but not generic enough IMO.
With lazy initialization for instance
it will also be nice to pack the id
of the offending component along with
the exception but we won't have a CompositeException
to wrap it into then.
4)
Pack the id into the Exception itself.
The cleanest way, isn't it?
Just what the Exception-s are for.
<disclaimer>
Gentlemen, I want to remark in advance
that I will not feel at all offended if
I hit a rock and it hurts, if I ask about
extending some fundamentals of Avalon and
I meet resistance - so please, no excuses,
we are mates here -- I just love this word :-)
so no bad feeling on my side will come - so
no excuses, please!
</disclaimer>
Gentlemen it's beginning to be funny -- but
again I feel like proposing to extend the Framework! :-)))
ROTFL :-))
But I do!
We need to pack info on the component that caused
an exception along with the info itself!
Does it best fit to CascadingException? Or where?
Okay, it must be too late now for me to decide this,
but looks like the id should somehow be packed into
the exception signalling its failure. Perhaps a
Fortress-private exception
* ComponentStartupFailed
* ActivationFailed
or something like this, it will have the id attached
and enclose the exception.
5)
Now the user-developer should be prepared to deal with it.
Here we continue section 1) of this mail (plz see it again :-)
I believe the algorithm should be the following:
StringBuffer sb = new StringBuffer();
buildMessage( e, sb );
buildMessage( Throwable t, StringBuffer sb )
{
if ( e instanceof CompositeException )
{
for ( member in e.getExceptions() )
{
buildMessage( member, sb )
}
}
else
{
eHasId = e carries a component id;
if ( eHasId )
{
sb.append( "Activation failed for '" + e.id + "'
because of");
}
if ( eHasId && e is a "safe and envisioned" exception )
{
sb.append( getLastPart(e.getClass.getName()) +
e.getMessage() );
}
else
{
/* we did not envision this. give the stack trace
and thus force user-user to call the support,
something really bad happened */
sb.append( e.getStackTrace() );
}
if ( e.getCause() != null )
{
sb.append( " caused by\n" );
buildMessage( e.getCause, sb );
}
}
}
Quite a bit of work. And this work is quite standard.
Probably we shouldn't load user with it. But who then?
I guess we should either teach all our loggers to do that
or just to provide an utility method somewhere to do that.
Again: to late an hour for me to make my mind :-)
6)
For this all to work smoothly with in particular
ConfigurationException we should make sure that
a) correct info on what component triggered the exception
be available (with a stack trace we would deduct
better or worse from the classname of the component)
but if we cut the trace we strictly need the id
b) the best possible info on the location of the
offending element inside the configuration file
We have covered a) in section 4.
Lets look closer at b). This info is available
from Configuration.getLocation(). Now we have to hook
it into the ConfigurationException. Currently I just
attach it to the message like
new ConfigurationException( message + " at " + conf.getLocation())
however we should probably consider extending the
ConfigurationException with the info on location.
(Yes, again, extending the Framework, I must be mad :-)
What experience did you have gentlemen with this info
being kept separate from the message in SAXExcepton?
Good or Bad?
7)
ServiceManager exception. It looks pretty safe
not to print stack if we have the id of the
component that has caused it. We know what
ServiceManager it operates upon.
8)
And, a bit aside from this.
What on earth is a use case for background
activation of components (Fortress)?
Are these these the "active" components.
They do not passive. They do service incoming
servlet requests, they do not serve incoming JMS
messages, nothing.
Instead they are active. They send requests.
They send JMS messages.
Am I right?
If yes, then what should happen to the system
if activation of such component fails.
Nothing? Run okay?
This makes activation=="background"
identical to the notion of "optional" component,
not "optional" that can be configured on not be configured,
but "optional" that may start and may not start.
Was this the intent?
If no, how can we fix this?
If we decide that all the components are required,
then how do we shutdown the system once a "background"
component fails initialization?
And what about lazy initialization?
Do I get correctly that the inability to activate
a lazily-activatable component never will cause the
whole system to shut-down?
Oh, enough for one poor day,
WBR, Anton Tagunov
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
