Anton,
I'm jumping in on the discussion a bit late, so you may already
have covered this ground - but I must admit to not really
seeing the purpose of minimizing stack traces by not printing
stack traces for certain exceptions.
The general consensus appears to be that if any component
fails, the whole container & all components in it are essentially
completely broken.
Thus, these exceptions should happen very rarely.
But when they do happen, having a full stack trace is very
helpful. In fact, a constant annoyance for me is that
an exception thrown in a SAX ContentHandler gets wrapped
in a SAXException and appears like one, requiring manual
unwrapping in order to figure out just what really happened!
So policy should be this:
1. Always err on the side of printing when printing
stack traces. Print too much rather than too little.
2. It is better to just *stop* the initialization process
at the first exception.
/LS
> -----Original Message-----
> From: Anton Tagunov [mailto:[EMAIL PROTECTED]
> Sent: den 13 juni 2003 01:02
> To: Avalon Developers List
> Subject: [RT] Minimizing stack traces on startup.
>
>
> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
