On Jan 17, 2007, at 12:54 PM, Ignacio Silva-Lepe wrote:
Hi Jim,
I am not sure I follow the modification to ConnectorImpl. You remove
the check for operationHasCallback altogether in the forward direction
and add a check for isOneWayOperation in the callback direction.
As far I understand, Operation.isNonBlocking (which determines the
value of isOneWayOperation) is only true when there is a @OneWay
annotation.
Yes, that is correct.
Are we supposed to use @OneWay explicitly to make forward and
callback methods non-blocking now?
Yes
It seems to me to be the only
way in which ConnectorImpl can produce the right outcome as it
currently stands. If so, is the spec going to change to require the
use of @OneWay for this purpose?
The Java spec could be worded better but this is the current behavior
mandated by the spec. In terms of callbacks, there are a couple of
scenarios:
1. Sync forward, sync callback
2. Sync forward, non-blocking callback
3. Non-blocking forward, sync callback
4. Non-blocking forward, non-blocking callback
Scenarios 1-2 are important when the target needs to provide a
response to the forward invocation prior to a callback, e.g. a loan
application sends back a confirmation number before the "loan
approved" callback is made. I've updated the connector to support all
of these scenarios.
At the moment, both the simplecallback and the inner.composite
samples do not work properly.
I think they should work correctly according the the semantics where
non-blocking behavior needs to be stated on operations.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
