Ignacio,
It's true that non-void returns are mux with non-blocking, but
that's not the point being made. The point is that
non-blocking and bidirectional are orthogonal.
Dave
----- Original Message -----
From: "Ignacio Silva-Lepe" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, January 12, 2007 1:09 PM
Subject: Re: Callback methods w/ non-void return types
>I agree with you, the spec does not explcitly rule this out.
Although I
>have
> not participated in spec discussions about this, it seems to me
that,
> unless
> a special type is returned (something like >
java.lang.concurrent.Future),
> non-
> void return values and non-blocking are mutually exclusive. Adding
> j.l.c.Future
> as an option would have to be explicitly specified, so it seems
reasonable
> to
> me to assume that in its absence void should be assumed for
non-blocking.
>
>
> On 1/12/07, Scott Kurz <[EMAIL PROTECTED]> wrote:
>>
>> So Jim and Ignacio are both assuming that each of the "forward
half"
and
>> the
>> "backward half" return void.
>>
>> But I don't see where in any spec this is stated. Where does
it say
>> that
>> in SCA a bidirectional interface can't have one or both "halves"
>> returning non-void data?
>>
>>
>> On 1/12/07, Ignacio Silva-Lepe <[EMAIL PROTECTED]> wrote:
>> >
>> > FWIW, I'll try to respond to both Scott and Matt. Say we
have a bi-
>> > directional interface consisting of FI.cf and BI.cb, where
FI is the
>> > forward half and BI is the backward half. We agree that both
the
>> > call forward method cf and the callback method cb return
void. If >> > the
>> > call to FI.cf blocked, the question then would be until when
and >> > what
>> > for? Since the result to cf will be coming in the invocation
to cb,
>> there
>> > seems to be no purpose in blocking cf, and unblocking it would
require
>> > some coordination, e.g. with the call to cb, by the system.
>> > As for the call to cb (by the service that implements cf)
the local
>> > implementation is actually blocking, it does not seem to be
>> > necessary
>> > to spawn another thread for this.
>> > Does this address what you were trying to get at?
>> >
>> > Given the above, the connector assumes that a bi-directional
interface
>> > is non-blocking an inserts a NonBlockingBridgingInterceptor,
which >> > in
>> > turn assumes that the return type of the forward call is
void and
thus
>> > returns a message with a null body, which is probably the
cause of
>> > your NPE.
>> >
>> >
>> > On 1/12/07, Matthew Sykes <[EMAIL PROTECTED]> wrote:
>> > >
>> > > Jim,
>> > >
>> > > I'm interested in the answer to this as well. I think we all
>> understand
>> > > that non-blocking operations must have void return types.
The
>> question
>> > > really boils down to whether or not bidirectional services
are
>> > > considered non-blocking.
>> > >
>> > > I have a simple piece of code that uses a bidirectional
service in
>> which
>> > > the service and callback operations both return data. The
code
>> > > currently fails with an NPE because the ConnectorImpl code
uses >> > > the
>> > > NonBlockingBridgingInterceptor when a callback is
defined. I >> > > can't
>> see
>> > > anything in the spec that would preclude this.
>> > >
>> > > Thanks.
>> > >
>> > > Scott Kurz wrote:
>> > > > Jim,
>> > > >
>> > > > OK, but are all callback operations necessarily non-
blocking?
>> > > >
>> > >
>> > >
--------------------------------------------------------------------
-
>> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > > For additional commands, e-mail: tuscany-dev-
[EMAIL PROTECTED]
>> > >
>> > >
>> >
>> >
>>
>>
>
--------------------------------------------------------------------
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
