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