You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leif Mortenson <le...@tanukisoftware.com> on 2003/06/11 17:26:28 UTC
[Fortress] Minimizing stack traces on startup.
I have been working on getting some of my customers interested in using
Avalon and Fortress here in Japan. So far there has been a lot of interest.
One comment that came up, which I have also thought about as well, is why
Fortress continues to attempt to initialize additional components after one
has failed.
For example I have an application which defines a DataSource component
which is then looked up by 8 other components. When things are configured
correctly, all works great. But if there is any problem with the
configuration
of the DataSource component, Fortress will kick out an impressive chain of
stack traces that fills a couple hundred lines in a log file. The log output
gets more impressive the deeper in the dependency tree an error occurs.
Fortress will correctly print a stack tract for the problem in the
DataSource
component. But it will then continue on and attempt to configure each of the
other components as well. All 8 of the components which depend on the
DataSource will also print out stack traces when they fail to look up the
DataSource.
As I recall, ECM behaved this way as well. My question is there a reason
why the container should not be giving up on the first failure and exiting?
It seems like it should be the responsibility of an individual component to
catch an exception during initialization if it should not stop the container
for completing its initialization.
If there are reasons for doing this what would you think of the idea of
adding a way to configure Fortress so that the container's initialization
will immediately fail if any of its components' initialization fails. I
would
also like to be able to configure things so that the exception message
which causes initialization to fail is displayed in the console/log. But be
able to avoid showing large stack traces.
The stack traces have been fine when I have installed applications myself.
But I have been running into problems lately trying to explain them away
to customers who simply make a typo in the config file while deploying
an application themselves.
I can of course work on this myself, but I wanted to understand the issues
which led to the way things are currently implemented.
Cheers,
Leif
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Fortress] Minimizing stack traces on startup.
Posted by Peter Royal <pr...@apache.org>.
On Thursday, June 12, 2003, at 12:29 AM, Leif Mortenson wrote:
> Rather than this:
> getLogger().error( msg, e );
>
> I do this:
> getLogger().error( msg + " : " + e.getMessage() );
> getLogger().debug( "Stack Trace:", e );
>
> Or something along those lines. It really depends on the context.
You've found that that approach works better than having a "user" log
that doesn't include stack-traces in the formatter and a "dev" log that
does?
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Fortress] Minimizing stack traces on startup.
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Rather than this:
getLogger().error( msg, e );
I do this:
getLogger().error( msg + " : " + e.getMessage() );
getLogger().debug( "Stack Trace:", e );
Or something along those lines. It really depends on the context.
Cheers,
Leif
Anton Tagunov wrote:
>Hello Leif!
>
>LM> The stack traces are obviously invaluable during development and even
>LM> for debugging problems in a deployed application.
>LM> But they also need to be invisible to the end users.
>
>LM> I usually do this on a component level by only showing stack traces at the
>LM> debug priority.
>
>Very interesting!
>
>What I do, I have a number of expected exceptions that I know
>I won't need a stack trace for (f.e. ConfigurationException)
>and do it like this
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re[2]: [Fortress] Minimizing stack traces on startup.
Posted by Anton Tagunov <at...@mail.cnt.ru>.
Hello Leif!
LM> The stack traces are obviously invaluable during development and even
LM> for debugging problems in a deployed application.
LM> But they also need to be invisible to the end users.
LM> I usually do this on a component level by only showing stack traces at the
LM> debug priority.
Very interesting!
What I do, I have a number of expected exceptions that I know
I won't need a stack trace for (f.e. ConfigurationException)
and do it like this
try{
FortressConfig fortressConfig = ...;
DefaultContainerManager containerManager = ...;
containerManager.initialize();
return (Foo) containerManager.getContainer();
}
catch( Fatal f )
{
/**
* This is the exception that is thrown if error
* has alredy been logged
*/
return null;
}
/**
* Now we'll enumerate the exceptions for which we want
* only the message and no stack trace.
*/
catch( ConfigurationException ce )
{
/* this in effect is just
* m_logger.log( message )
*/
fatal( ce.getMessage() );
return null;
}
catch( LinkageError le )
{
fatal( le.toString() );
return null;
}
catch( Throwable t )
{
/**
* We did not expect this error - we need a stack trace.
*/
fatal( "Initialization failed", t );
return null;
}
Which approach is more powerfull?
LM> Would that be an option worth considering for the
LM> container as well?
I know you've been asking Berin, but you have also
given me some thinking food.. Don't know ATM.
- Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Fortress] Minimizing stack traces on startup.
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Berin Loritsch wrote:
> We have the dependency information recorded now, so we can fail early if
> there are missing dependencies. We are ignoring the "optional"
> attribute for now, but we should probably add that in now.
>
> The issue derives from the following scenario:
>
> 1) ECM had zero dependency tracking, so there was no way to tell which
> components were needed or not.
>
> 2) Fortress has limited dependency tracking, but there is no way to tell
> which components are *required* or not.
>
> 3) If you cannot tell if a component is required or not, maybe it isn't
> so keep on going.
I was thinking of optional dependencies as meaning that component A
defines an optional dependency on B. So when component A executes
its service method, it will attempt to lookup B and in the event that B does
not exist, the component will eat the ServiceException and continue. In
the case where component B is required, then the ServiceException
would be thrown and initialization of component A would fail.
So this is the case where the xconf file only contains a definition for
component A. The service defined by component B was not needed
for a particular application and was thus not defined. The system should
continue without it.
The other case is where the user has defined both A and B in the xconf
file. In this case, component B may be optional with respect to
component A. But it is is required by the application as a whole.
Fortress would use the dependency tree to decide that the initialization
order is B->A and proceed.
Are there any possible scenarios where the application would want to
keep trying to initialize if component B fails to initialize for any reason?
It seems like the rare case where you would want to continue would be
the exception.
> So if we add a "synchronization" point so that we can be notified when
> all components have been asynchronously initialized, we can perform the
> proper validation and shut down if any required component is not
> available.
>
> If an optional component is not available, then we should place a
> warning in the log file, but not shut down. We need to keep track of
> whether initialization is done for a component or not, so we don't
> attempt a repeat....
Yes currently, B would be initialized and then fail. Fortress would then
attempt to initialize A which requires B, so B gets another chance to fail.
In any event, the attempt to lookup B should be failing without a second
attempt to initialize the component.
> It is doable.
:-) So was going to the moon. It doesn't sound like something I can have
working by Monday though :-)
What would be the ideal way for Fortress to handle initialization failures.
I have found that even a single stack trace will generate a support call
almost immediately. Customers tend not to notice the nice little error
message when its up at the top of a deep stack trace.
The problem is how to set things up so that the stack traces can be
configured. Maybe even within the xlog file. The stack traces are
obviously
invaluable during development and even for debugging problems in a
deployed application. But they also need to be invisible to the end users.
I usually do this on a component level by only showing stack traces at the
debug priority. Would that be an option worth considering for the
container as well? At least for component initialization? That in and
of itself
would reduce the log output to a few lines of error messages.
Cheers,
Leif
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Fortress] Minimizing stack traces on startup.
Posted by Peter Royal <pr...@apache.org>.
On Wednesday, June 11, 2003, at 11:53 AM, Berin Loritsch wrote:
> If an optional component is not available, then we should place a
> warning in the log file, but not shut down. We need to keep track of
> whether initialization is done for a component or not, so we don't
> attempt a repeat....
I think the system should shut down if any declared components fail
initialization.
Optional means "it doesn't have to be declared" to me, not "its okay to
fail if it is declared"..
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Fortress] Minimizing stack traces on startup.
Posted by Berin Loritsch <bl...@apache.org>.
Peter Royal wrote:
> On Wednesday, June 11, 2003, at 11:26 AM, Leif Mortenson wrote:
>
>> One comment that came up, which I have also thought about as well, is why
>> Fortress continues to attempt to initialize additional components
>> after one
>> has failed.
>
>
> It is due to the async initialization of components. There is a command
> in the queue to initialize each component, and when one fails, the queue
> continues to process commands.
> -pete
There are ways around that though...
Hmm.
We have the dependency information recorded now, so we can fail early if
there are missing dependencies. We are ignoring the "optional"
attribute for now, but we should probably add that in now.
The issue derives from the following scenario:
1) ECM had zero dependency tracking, so there was no way to tell which
components were needed or not.
2) Fortress has limited dependency tracking, but there is no way to tell
which components are *required* or not.
3) If you cannot tell if a component is required or not, maybe it isn't
so keep on going.
So if we add a "synchronization" point so that we can be notified when
all components have been asynchronously initialized, we can perform the
proper validation and shut down if any required component is not
available.
If an optional component is not available, then we should place a
warning in the log file, but not shut down. We need to keep track of
whether initialization is done for a component or not, so we don't
attempt a repeat....
It is doable.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re[2]: [Fortress] Minimizing stack traces on startup.
Posted by Anton Tagunov <at...@mail.cnt.ru>.
Hello Leif!
1)
The matter has attracted my interest too.
Please tell me, what did you end up with?
If I understand correctly you wanted your
system not to startup if any of the components
failed to initialize and you wanted
the log to be quite, right?
So, what do you do now?
Pass in your own CommandFailureHandler that returns true
for PrepareHandlerCommand?
2)
Looks like the current Fortress is sort out of line now:
* if initialization fails for an inline-initialized
component the system just refuses to startup
(although the stack traces are still long) -
an exception is thrown from AbstractContainer.initialize()
* if initialization fails for a background-initialized
component the system runs up (with the default
CommandFailureHandler)
Am I correct?
There was an idea of using the CommandFailureHandler
for the AbastractContainer.initialize() too, wasn't it?
Is it still "on the table"?
If yes, how do we pass this handler to the container,
it seems
* not proper in contextualize() - not a constant
* a bit more proper service() ? But still somewhat
awkward...
3)
BTW if this handler is to be made available to
AbstractContainer the CommandFailureHandler
interface seems too general - we do not need
to handle general Command failures but specifically
component configuration/initialization exceptions..
This has all set me up thinking on the matter...
4)
LM> config.setCommandFailureHandlerClass( String );
How about adding
FortressConfig.setCommandFailureHandler( CommandFailureHandler )
for symmetry?
- Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
[RT] Minimizing stack traces on startup. Iteration II
Posted by Anton Tagunov <at...@mail.cnt.ru>.
Hi, All!
The idea to have a list of exceptions for which
we do not need a stack trace looks quite reasonable
to me.
In fact the list could be something like
ConfigurationException
ServiceException
ContextException
How, this functionality - legging or not logging
the stack traces can be located in one of the 3 places:
1) in user code
for instance
a)
try{ cm = new ContainerManager( config ); cm.initialize() }
catch( ConfigurationException ce ){ log only getMessage(); }
catch( ServiceException se ){ log only getMessage(); }
catch( ContextException ce ){ log only getMessage(); }
catch( Throwable t ){ log the full stack trace }
b)
class CustomLogFormatter implements xxxFailureHandler
{
...handlexxx...( Throwable t )
{
if ( t instanceof ConfigurationException ||
t instanceof ServiceException ||
t instanceof CotnextException )
{
log only getMessage()
}
else
{
log the full stack trace
}
}
}
fortressConfig.setXxxxFailureHandler( new CustomLogFormatter() );
2) in LoggerManager
lm = new StackTraceSupressingLoggerManagerDecorator(
new LogKitLoggerManager(...),
new Class[]{
ConfigurationException.class,
ServiceException.class,
ContextException.class
} );
fortressConfig.setLoggerManager( lm );
and this decorator would wrap any Logger returned
from the wrapped LoggerManager with a
StackTraseSuppressingLogger( Logger, Class[] )
that would do the filtering
3) in logging backend
imagine we create a new LogKit formatter with
the following configuration
<formatter>
..%{message}...
<no-stack>
ConfigurationException
ServiceException
ContextException
</no-stack>
------------------
So, where should we put it?
3) looks the nicest to me, but then what to do
about Log4J logging backend?
- Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Re[3]: [RT] Minimizing stack traces on startup.
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Peter Royal [mailto:proyal@apache.org]
> > 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
>
> I like this.
>
> As for stack trace suppression, I believe that should be done at the
> logger level, rather than having 'no stack traces' be hardcoded. -pete
Agreed. (Configurable at logger level, not hard coded).
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Re[3]: [RT] Minimizing stack traces on startup.
Posted by Peter Royal <pr...@apache.org>.
On Friday, June 13, 2003, at 07:15 AM, Anton Tagunov wrote:
> 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
I like this.
As for stack trace suppression, I believe that should be done at the
logger level, rather than having 'no stack traces' be hardcoded.
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re[3]: [RT] Minimizing stack traces on startup.
Posted by Anton Tagunov <at...@mail.cnt.ru>.
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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re[2]: [RT] Minimizing stack traces on startup.
Posted by Anton Tagunov <at...@mail.cnt.ru>.
Hello Leo!
LS> I'm jumping in on the discussion a bit late, so you may already
LS> have covered this ground
No you're not! It's who is turning the discussion into this side.
It's me who comes up with the idea of cutting the stack trace
based on the exception type. So all comments welcome! :-)
LS> - but I must admit to not really
LS> seeing the purpose of minimizing stack traces by not printing
LS> stack traces for certain exceptions.
Well, I think some exceptions are expected.
ConfigurationException is expected when users supply
invalid configuration.
Moreover, if we make sure this exception alone carries enough
info to trace the problem, e.g. it has
* Configuration.getLocation() including full path name and line
number
* the id and probably type of the offending component
(that's what I'm thinking about - probably subclassing
ConfigurationException and adding the info there, or
putting it somehow into message, or changing the
ConfigurationException itself, or changing
CascadingException - you see I'm not afraid to touch
the most sacred things :-)
Anyway, if ConfigurationException has both location and
coponent information then we do not need a stack trace.
(Or need it when the level of logging is debug)
Moreover, a component id is somewhat better then
a stack trace. Stack trace gives only the class the caused
the exception and if we have several components of the same
class but with different ids, the id is better.
So, ConfigurationException is expected (as users mistype
the configuration for instance) and it is nice to print
only component id + location for it.
Now, if one component failed to startup we can either
* stop immediately (it would be okay to me)
* or do what currently fortress/impl/AbstractContainer.initialize()
does - try to bring up all we can, collect all the exceptions
and fail after that (I do not mind that also)
Well, I sort of do not want to change much if I can change little.
If AbstractContainer collects exceptions into a CompositeException
I do not mind.
But then I would like to nicely handle these exceptions also.
In fact if component A failed because it could not get component B
we also do not need a stack trace for this (unless we're at
DEBUG log level). So I was trying to break a path for it too.
To me the path looks somewhat like this: such a failure
most likely will be expressed as a ServiceException.
Very good. Now we should make sure that the ServiceException
has info conveyed on the id of the component _on behalf of which
the operation was attempted_ (again like with ConfigurationException
there are a plethora of options where we can put this info) and
we're fine: we do not need a stack trace again.
Same with ContextException, looks like we avoid the stack trace.
(But ContextException probably got into the list by mistake,
the original intention was to catch a ConfigurationException,
handle it nicely w/o a stack trace and handle the subsequent
ServiceExceptions equally nicely. Leif has made a valid point
that users get very frightened by stack traces and call him
for support as soon as they see one and I have found that
I'm doing exactly the same in my user code - I omit stack
traces for Cofiguration exceptions and I am very pleased
with the result so far.
Peter Royal has yet another approach: he has suggested
to have two logs: one user log without exceptions and
one developer's log with exceptions. Very nice indeed.
But I got to like so much to get little quite error
messages w/o stack traces in the developer's log too,
that I found it reasonable to continue discussion on
the topic. This is something I'm doing for myself
anyway. Probably this has value. Discussion will show! :-)
LS> The general consensus appears to be that if any component
LS> fails, the whole container & all components in it are essentially
LS> completely broken.
That would be fine by me, but currently Fortress runs differently.
And there some caveats: for instance with lazy or background
initialization how can you shut down the system if a component
initialization fails? So this probably works only with inline
initialization. Activation policy inline has (unintentionally?)
become the 'required component' policy as well.
LS> Thus, these exceptions should happen very rarely.
In fact I only want some certain cases (like broke config)
to be logger w/o stack traces. Of course all the unforseen
circumstances (including these rare catastrophes should be
logger completely, and if we're talking about this, it's
probably okay to make users call support in this case!).
LS> But when they do happen, having a full stack trace is very
LS> helpful. In fact, a constant annoyance for me is that
LS> an exception thrown in a SAX ContentHandler gets wrapped
LS> in a SAXException and appears like one, requiring manual
LS> unwrapping in order to figure out just what really happened!
Errr... terrible...
To me 2 things are BAD about SAX exception:
* the toString() method is just an assassination of a sane
mind to be invoked - calling toString() of the nested
exception - it is more then terrible IMO!
* a nesting mechanism different from getCause()
yes, I guess SAXException was invented before JDK 1.4 :-)
but now its a problem
The solution IMO is
a) never call toString() on SAXException (and hence on
any exception probably), but to use
t.getClass().getName() + ": " + t.getMessage()
(getMessage() does not seem to be broken on SAXException
if I'm not mistaken)
if I'm not mistaken our current loggers all behave like this
b) to unwind nested exceptions not only look at getCause()
but also check to see if we're dealing with a SAXException
and in the latter case handle getException() identically
to getCause(). Our logger do not do that ATM, AFAIK.
Probably will teach them one day to do that.
Or you will :-)
I guess we could easily put that into Avalon formatter.
Probably even in other formatters in log kit?
Do you know by any chance what does Log4J do about it?
And don't get me wrong: when I speak about cutting stack
traces I _by no means do not want to_ cut nested exception
unwinding as well.
To be true I was thinking about adding the following formatter
to LogKit
<formatter>
<format> ... %{message}.. </format>
<no-stack>
ConfigurationException
ServiceException-
</no-stack>
</formatter>
you see those minus? ('-')?
I wanted it to denote that the nested exceptions shouldn't
be unwinded for that exactly exception. But I wanted that
to be optional.
Instead I wanted the unwinding to happen, but the stacks
to be cut _at the inner levels too_ by the same rule for
all levels. So we could have
ActivationFailedException: id='k'
caused by: ConfigurationException: id='k': foo bar:file:/D:/conf/a.xconf:22
caused by: ... (why not?)
LS> So policy should be this:
LS> 1. Always err
?? what is it ?? :-)
LS> on the side of printing when printing
LS> stack traces.
LS> Print too much rather than too little.
Well my preference would be for this to happen only
when log level is DEBUG.
I keep more to Leif's opinion that it the stack traces should
be cut for ConfigurationException rather then with Peter Royal's
that we should have two logs (may change my mind in the future :-)
LS> 2. It is better to just *stop* the initialization process
LS> at the first exception.
It would be okay by me, but
a) it is not now that way
b) lazy and background initialization policies spoil this nice
intention to fail fast, don't they?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] Minimizing stack traces on startup.
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
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:atagunov@mail.cnt.ru]
> 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: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
[RT] Minimizing stack traces on startup.
Posted by Anton Tagunov <at...@mail.cnt.ru>.
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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Fortress] Minimizing stack traces on startup.
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Berin Loritsch wrote:
>> It looks like the next step is to create a
>> FortressCommandFailureHandler in
>> Fortress and then set it in the ContextManager.createCommandSink
>> method.
>
>
> Go for it.
Done. Let me know if there was anything you would like to see done
differently.
Currently you can set a new handler using the following code:
FortressConfig config = new FortressConfig();
config.setContainerClass( getContainerClassName() );
config.setCommandFailureHandlerClass( ServerCommandFailureHandler.class );
config.setContextDirectory( "./" );
...
Cheers,
Leif
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Fortress] Minimizing stack traces on startup.
Posted by Berin Loritsch <bl...@apache.org>.
Leif Mortenson wrote:
> Berin Loritsch wrote:
>
>> Done....
>
>
> Not that I mind with the workload I am currently under. But Hey! Give the
> rest of us a chance to code sometimes!! :-) But seriously. Thanks.
Ask and ye shall receive ;P
>
> It looks like the next step is to create a FortressCommandFailureHandler in
> Fortress and then set it in the ContextManager.createCommandSink
> method.
Go for it.
>
> Something like this:
>
> public class FortressCommandFailureHandler
> extends AbstractLogEnabled
> implements CommandFailureHandler
> {
> /**
> * Handle a command failure. If a command throws an exception, it
> has failed. The
> * CommandManager will call this method so that we can handle the
> problem effectively.
> *
> * @param command The original Command object that failed
> * @param throwable The throwable that caused the failure
> * @return <code>true</code> if the CommandManager should cease to
> process commands.
> */
> public boolean handleCommandFailure( Command command, Throwable
> throwable )
> {
> if ( command instanceof PrepareHandlerCommand )
> {
> PrepareHandlerCommand phc = (PrepareHandlerCommand)command;
> if ( getLogger().isErrorEnabled() )
> {
> getLogger().error( "Could not prepare ComponentHandler
> for: " + phc.getHandler().getComponentClass().getName(), e );
> }
> }
> return false;
> }
> }
>
> The PrepareHandlerCommand would then need to be modified so that it
> does not do any logging on its own. And to provide access to its handler.
>
> We would then need to have a way for user code to override the use of the
> FortressCommandFailureHandler.
>
> Is this along the lines of how you were thinking of implementing this?
>
> Cheers,
> Leif
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Fortress] Minimizing stack traces on startup.
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Berin Loritsch wrote:
> Done....
Not that I mind with the workload I am currently under. But Hey! Give the
rest of us a chance to code sometimes!! :-) But seriously. Thanks.
It looks like the next step is to create a FortressCommandFailureHandler in
Fortress and then set it in the ContextManager.createCommandSink
method.
Something like this:
public class FortressCommandFailureHandler
extends AbstractLogEnabled
implements CommandFailureHandler
{
/**
* Handle a command failure. If a command throws an exception, it
has failed. The
* CommandManager will call this method so that we can handle the
problem effectively.
*
* @param command The original Command object that failed
* @param throwable The throwable that caused the failure
* @return <code>true</code> if the CommandManager should cease to
process commands.
*/
public boolean handleCommandFailure( Command command, Throwable
throwable )
{
if ( command instanceof PrepareHandlerCommand )
{
PrepareHandlerCommand phc = (PrepareHandlerCommand)command;
if ( getLogger().isErrorEnabled() )
{
getLogger().error( "Could not prepare ComponentHandler
for: " + phc.getHandler().getComponentClass().getName(), e );
}
}
return false;
}
}
The PrepareHandlerCommand would then need to be modified so that it
does not do any logging on its own. And to provide access to its handler.
We would then need to have a way for user code to override the use of the
FortressCommandFailureHandler.
Is this along the lines of how you were thinking of implementing this?
Cheers,
Leif
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Fortress] Minimizing stack traces on startup.
Posted by Berin Loritsch <bl...@apache.org>.
Leif Mortenson wrote:
> Berin Loritsch wrote:
>
>> It would look like this:
>
>
> You mean "It looks like this:" That looks like an example that is about
> ready
> to be committed. :-)
Done....
>
>> /**
>> * CommandFailureHandler is used by the CommandManager to handle any
>> exceptions that might
>> * be thrown by a Command. That way the application using the
>> CommandManager can properly
>> * manage what happens when an exception is thrown.
>> *
>> * @author <a href="bloritsch.at.apache.org">Berin Loritsch</a>
>> * @version CVS Revision: 1.1 $
>> */
>> public interface CommandFailureHandler
>
>
> ...
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Fortress] Minimizing stack traces on startup.
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Berin Loritsch wrote:
> It would look like this:
You mean "It looks like this:" That looks like an example that is about
ready
to be committed. :-)
> /**
> * CommandFailureHandler is used by the CommandManager to handle any
> exceptions that might
> * be thrown by a Command. That way the application using the
> CommandManager can properly
> * manage what happens when an exception is thrown.
> *
> * @author <a href="bloritsch.at.apache.org">Berin Loritsch</a>
> * @version CVS Revision: 1.1 $
> */
> public interface CommandFailureHandler
...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Fortress] Minimizing stack traces on startup.
Posted by Berin Loritsch <bl...@apache.org>.
Leif Mortenson wrote:
>
> However. It seems that everyone agrees that a defined component which
> fails to initialize should cause the container to fail to initialize.
> Should we
> also modify the AbstractContainer.initialize method so that it fails
> immediately rather than building up a list of failures in a "buffer" as is
> currently being done? The behavior could be controlled by maybe adding
> an optional "required='true/false'" to component declarations?
The required true/false can be determined if we keep track of optional
dependencies.
IOW all components are considered optional unless they are referenced
as required (the current default).
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Fortress] Minimizing stack traces on startup.
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Berin Loritsch wrote:
> You might want to wait until Event is released again. I don't know
> how much of a stickler your clients are for using unreleased code.
What they don't know.... Customers usually accept applications as a
whole and don't tend to dig into the code, which is what the jars are as
far as they are concerned.
Actually I tend to keep tested jars in the CVS repositories of various
projects. I then attempt upgrades to newest code while maintaining the
ability to fall back to a version that is known to work correctly. This has
usually worked out well because Avalon code is in general quite high in
quality with lots of tests for most of the code.
Cheers,
Leif
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Fortress] Minimizing stack traces on startup.
Posted by Berin Loritsch <bl...@apache.org>.
Leif Mortenson wrote:
> Looking at my stack traces. I was noticing that what you are talking about
> with the CommandManager and a CommandFailureHandler is what
> happens when when the components are configured to be initialized in
> the "background".
>
> I have been using "inline" to make sure that all of my components are
> initialized on startup. Looking at the initialize method of
> AbstractContainer, it does not look like the CommandManager is even
> used as the handlers are prepared inline.
You might want to wait until Event is released again. I don't know
how much of a stickler your clients are for using unreleased code.
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Fortress] Minimizing stack traces on startup.
Posted by Berin Loritsch <bl...@apache.org>.
Leif Mortenson wrote:
> Looking at my stack traces. I was noticing that what you are talking about
> with the CommandManager and a CommandFailureHandler is what
> happens when when the components are configured to be initialized in
> the "background".
>
> I have been using "inline" to make sure that all of my components are
> initialized on startup. Looking at the initialize method of
> AbstractContainer, it does not look like the CommandManager is even
> used as the handlers are prepared inline.
>
> That said however, The reason that I have been using the inline
> initialization
> was because any inline components which fail to initialize will cause the
> container as a whole to also fail. This was letting me shutdown the
> application.
>
> With the CommandFailureHandler, I think I would be able to switch back to
> using "background" initialization and then shutdown the application from
> within the handleCommandFailure method as needed.
>
> However. It seems that everyone agrees that a defined component which
> fails to initialize should cause the container to fail to initialize.
> Should we
> also modify the AbstractContainer.initialize method so that it fails
> immediately rather than building up a list of failures in a "buffer" as is
> currently being done? The behavior could be controlled by maybe adding
> an optional "required='true/false'" to component declarations?
Well the CommandFailureHandler can also be used for container itself...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Fortress] Minimizing stack traces on startup.
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Looking at my stack traces. I was noticing that what you are talking about
with the CommandManager and a CommandFailureHandler is what
happens when when the components are configured to be initialized in
the "background".
I have been using "inline" to make sure that all of my components are
initialized on startup. Looking at the initialize method of
AbstractContainer, it does not look like the CommandManager is even
used as the handlers are prepared inline.
That said however, The reason that I have been using the inline
initialization
was because any inline components which fail to initialize will cause the
container as a whole to also fail. This was letting me shutdown the
application.
With the CommandFailureHandler, I think I would be able to switch back to
using "background" initialization and then shutdown the application from
within the handleCommandFailure method as needed.
However. It seems that everyone agrees that a defined component which
fails to initialize should cause the container to fail to initialize.
Should we
also modify the AbstractContainer.initialize method so that it fails
immediately rather than building up a list of failures in a "buffer" as is
currently being done? The behavior could be controlled by maybe adding
an optional "required='true/false'" to component declarations?
Cheers,
Leif
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Fortress] Minimizing stack traces on startup.
Posted by Berin Loritsch <bl...@apache.org>.
Leif Mortenson wrote:
> Berin Loritsch wrote:
>
>> I think I have a better idea. How about adding a CommandFailureHandler
>> to the CommandManager?
>>
>> Currently all exceptions are ignored by the CommandManager, but this
>> way we can have any application customize what it chooses to do in
>> the event of a failure. The return value will be a boolean value
>> for whether to close the CommandManager or not.
>
>
> I like this. If the displaying of the error was done in the default
> handler, then
> I could simply configure my own handler and it would be easy to display as
> much or as little as I want. That should make everyone happy.
>
> What parameters would be available in that context?
>
> boolean commandFailed( Throwable t, String role );
> Something like that? I have not looked at the code that closely.
It would look like this:
/**
* CommandFailureHandler is used by the CommandManager to handle any
exceptions that might
* be thrown by a Command. That way the application using the
CommandManager can properly
* manage what happens when an exception is thrown.
*
* @author <a href="bloritsch.at.apache.org">Berin Loritsch</a>
* @version CVS Revision: 1.1 $
*/
public interface CommandFailureHandler
{
/**
* Handle a command failure. If a command throws an exception, it
has failed. The
* CommandManager will call this method so that we can handle the
problem effectively.
*
* @param command The original Command object that failed
* @param throwable The throwable that caused the failure
* @return <code>true</code> if the CommandManager should cease to
process commands.
*/
boolean handleCommandFailure(final Command command, final Throwable
throwable);
}
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Fortress] Minimizing stack traces on startup.
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Berin Loritsch wrote:
> I think I have a better idea. How about adding a CommandFailureHandler
> to the CommandManager?
>
> Currently all exceptions are ignored by the CommandManager, but this
> way we can have any application customize what it chooses to do in
> the event of a failure. The return value will be a boolean value
> for whether to close the CommandManager or not.
I like this. If the displaying of the error was done in the default
handler, then
I could simply configure my own handler and it would be easy to display as
much or as little as I want. That should make everyone happy.
What parameters would be available in that context?
boolean commandFailed( Throwable t, String role );
Something like that? I have not looked at the code that closely.
Cheers,
Leif
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Fortress] Minimizing stack traces on startup.
Posted by Peter Royal <pr...@apache.org>.
On Wednesday, June 11, 2003, at 12:17 PM, Berin Loritsch wrote:
> I think I have a better idea. How about adding a CommandFailureHandler
> to the CommandManager?
>
> Currently all exceptions are ignored by the CommandManager, but this
> way we can have any application customize what it chooses to do in
> the event of a failure. The return value will be a boolean value
> for whether to close the CommandManager or not.
Sounds perfect :)
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Fortress] Minimizing stack traces on startup.
Posted by Berin Loritsch <bl...@apache.org>.
Peter Royal wrote:
> On Wednesday, June 11, 2003, at 11:55 AM, Leif Mortenson wrote:
>
>> That is what it looked like. Any ideas on how I could get the
>> behavior of simply
>> kicking out a message like "Password attribute not defined" and then
>> have the
>> application exit fairly gracefully. The message is what is being
>> thrown in the
>> ConfigurationException that is leading to the chain of failures in
>> dependent
>> components.
>
>
> Perhaps add an attribute to the Command objects of 'isFatal' or
> something and have the command manager stop processing commands if a
> fatal command fails to complete?
I think I have a better idea. How about adding a CommandFailureHandler
to the CommandManager?
Currently all exceptions are ignored by the CommandManager, but this
way we can have any application customize what it chooses to do in
the event of a failure. The return value will be a boolean value
for whether to close the CommandManager or not.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Fortress] Minimizing stack traces on startup.
Posted by Peter Royal <pr...@apache.org>.
On Wednesday, June 11, 2003, at 11:55 AM, Leif Mortenson wrote:
> That is what it looked like. Any ideas on how I could get the
> behavior of simply
> kicking out a message like "Password attribute not defined" and then
> have the
> application exit fairly gracefully. The message is what is being
> thrown in the
> ConfigurationException that is leading to the chain of failures in
> dependent
> components.
Perhaps add an attribute to the Command objects of 'isFatal' or
something and have the command manager stop processing commands if a
fatal command fails to complete?
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Fortress] Minimizing stack traces on startup.
Posted by Leif Mortenson <le...@tanukisoftware.com>.
>
>
>> One comment that came up, which I have also thought about as well, is
>> why
>> Fortress continues to attempt to initialize additional components
>> after one
>> has failed.
>
> It is due to the async initialization of components. There is a
> command in the queue to initialize each component, and when one fails,
> the queue continues to process commands.
That is what it looked like. Any ideas on how I could get the behavior
of simply
kicking out a message like "Password attribute not defined" and then
have the
application exit fairly gracefully. The message is what is being thrown
in the
ConfigurationException that is leading to the chain of failures in
dependent
components.
Cheers,
Leif
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Fortress] Minimizing stack traces on startup.
Posted by Peter Royal <pr...@apache.org>.
On Wednesday, June 11, 2003, at 11:26 AM, Leif Mortenson wrote:
> One comment that came up, which I have also thought about as well, is
> why
> Fortress continues to attempt to initialize additional components
> after one
> has failed.
It is due to the async initialization of components. There is a command
in the queue to initialize each component, and when one fails, the
queue continues to process commands.
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org