Berin Loritsch wrote:
Leif Mortenson wrote:
did not see where D-Haven project bugs should be posted. It sounds
like the
members are the same, so this should get into the right hands :-)
http://www.sf.net/projects/d-haven/
is the correct location.
However, since I am in both places, this will work :)
Great, got that bookmarked.
I am currently not using it directly so whatever fix fits in best with your design would beIf Fortress has any problems initializing any of its components then it is designed to call CommandFailureHandler failure. This defaults to the FortressCommandFailureHandler but it is possible to override it with one of your own. (As I have done).
The current trunk build now makes use of the d-haven-event jar and this has been broken.
Digging into the d-haven source, I see the problem:
When the DefaultCommandManager is instantiated, it initially sets its internal CommandFailureHandler to an instance of DefaultCommandFailureHandler. Then within the constructor, it immediately uses that handler to instantiate a new CommandEventHandler.
The DefaultCommandManager class has a setCommandFailureHandler method which is being called by Fortress after the constructor completes. But the problem is that it is already too late to be used. So my custom handler, and even the default FortressCommandFailureHandler is never used.
Either the instantiation of the CommandEventHandler is going to have to be
moved, or a way of changing its CommandFailureHander is going to have to
be introduced.
:/
Ok. I can easily make the event/failure handler replaceable, but what approach would make you happiest. I.e. what would be the easiest to work with?
I'll have to add a testcase to make the current action a failure...
fine. I am currently just specifying my handler class using the
FortressConfigsetCommandFailureHandlerClass( ) method.
In the Fortress ContextManager.createCommandSink() method, you are creating the
DefaultCommandManager, starting it and then setting the handler.
If you set the handler before starting the DefaultCommandManager then you could
maybe move all of the instantiation code from the constructor over to the start method.
Not sure how that fits into your overall design, but it would fix this particular problem.
Cheers, Leif
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Apache Excalibur Project -- URL: http://excalibur.apache.org/
