You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@excalibur.apache.org by Leif Mortenson <le...@tanukisoftware.com> on 2004/07/29 13:15:48 UTC
D-Haven-event bug in current Fortress trunk build.
I 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 :-)
If 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.
Cheers,
Leif
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/
Re: D-Haven-event bug in current Fortress trunk build.
Posted by Berin Loritsch <bl...@d-haven.org>.
Leif Mortenson wrote:
> Berin Loritsch wrote:
>
>> 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...
>
> 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.
>
I've fixed this issue, so there should be no problems. Event 1.0.2 will
be released momentarily.
--
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the Universe trying to
produce bigger and better idiots. So far, the Universe is winning."
- Rich Cook
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/
Re: D-Haven-event bug in current Fortress trunk build.
Posted by Leif Mortenson <le...@tanukisoftware.com>.
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.
>>If 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...
>
>
I am currently not using it directly so whatever fix fits in best with
your design would be
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: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/
Re: D-Haven-event bug in current Fortress trunk build.
Posted by Berin Loritsch <bl...@d-haven.org>.
Leif Mortenson wrote:
> I 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 :)
> If 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...
--
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the Universe trying to
produce bigger and better idiots. So far, the Universe is winning."
- Rich Cook
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/
Re: D-Haven-event bug in current Fortress trunk build.
Posted by Berin Loritsch <bl...@d-haven.org>.
Leif Mortenson wrote:
> I 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 :-)
>
> If 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.
This bug is also now fixed.
The next bug fix release should be posted sometime after lunch (starting
now). The build went successfully, and the tests make sure things are
happening well.
--
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the Universe trying to
produce bigger and better idiots. So far, the Universe is winning."
- Rich Cook
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/