Folks,
Comments inline
Yours, Mike.
Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
Email:
From:
C Vamsi <>
To:
David Booz <>
Cc:
Date:
11/02/2009 16:05
Subject:
Re: [sca-j] NEW ISSUE: @Callback injection
could be NULL
If a component is providing both bidirectional and
non-bidirectional
services isn't it an error in implementation if a method from
non-bidirectional service is using a callback?
<mje> Yes, it is an error in this case
</mje>
Also, a method from bidirectional service would expect access to a callback
service and if the callback service is not available, it may not be able
to
serve the request. This situation of NULL callback may not arise when
bidirectional service is invoked through SCA mechanism, as the interface
of
service and reference will have to match. (One of the situations I see
is
with EJBs providing bidirectional services. What should happen when the
EJB
is invoked as an EJB, not as an SCA service is out of the scope of the
current discussion I guess.)
<mje>
First the case of an SCA Java component:
It should never be the case that an implementation
of a bidirectional service ever gets called
on an operation of that bidirectional service without the
callback being available. Either the
callback gets injected or it is available via an API (latter case
is for composite scoped components in particular).
If the SCA runtime does not have the callback
available to inject, then there is a higher
level error and the runtime should raise an error and not
invoke the service implementation.
Second, the case of an EJB. I think
that EJBs should not be allowed to have bidirectional interfaces
that are accessible through EJB mechanisms
since (pure) EJBs don't support such semantics. This
needs to be addressed in the JEE specification.
</mje>
++Vamsi
Apache Tuscany Committer http://tuscany.apache.org
Apache Geronimo Committer and Member of PMC http://geronimo.apache.org
David Booz
<>
To
11/02/2009 20:12
cc
Subject
Re: [sca-j]
NEW ISSUE: @Callback
injection
could be NULL
I'm glad we're doing this in email, and not on the call. We need
to do
more of this.
We need to avoid uninitialized fields and so am asserting that NULL would
in fact be injected, ensuring that a test for NULL in the app was always
going to give the correct answer. This makes the two cases parallel
(which
they should be). It doesn't do the app any good to leave uninitialized
fields laying around.
Good catch on the "should".
I knew about the 76 overlap in the example and chose to ignore it given
that it hasn't been accepted/applied yet. In any case, I am fine
if we
omit the example updates from the proposal.
This then changes the proposal to:
In section 6.2.4, at the end of the first paragraph (line 395 [1] ) add
the
following:
A field or setter method annotated with @callback is injected or set to
NULL if the implementation is invoked through a non-bidirectional service
or when invoked as a callback. It is RECOMMENDED that the component
implementation checks for null before using a callback reference in this
situation (See also the getCallbackReference() method in section 8.2
"RequestContext").
Dave Booz
STSM, BPM and SCA Architecture
Co-Chair OASIS SCA-Policy TC and SCA-J TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:
(Embedded image moved to file: pic01519.jpg)Simon Nash ---02/10/2009
11:18:56 AM---David Booz wrote: > TARGET: Java CAA, section 6.2.4
"Accessing Callbacks" [1]
(Embedde (Embedded image moved to file: pic03501.jpg)
d image Simon Nash <>
moved to
file:
pic24194
.jpg)
From:
(Embedde (Embedded image moved to file: pic24729.jpg)
d image
moved to
file:
pic23250
.jpg)
To:
(Embedde (Embedded image moved to file: pic28022.jpg)
d image 02/10/2009 11:18 AM
moved to
file:
pic31249
.jpg)
Date:
(Embedde (Embedded image moved to file: pic30621.jpg)
d image Re: [sca-j] NEW ISSUE: @Callback injection could be NULL
moved to
file:
pic16408
.jpg)
Subject:
David Booz wrote:
> TARGET: Java CAA, section 6.2.4 "Accessing Callbacks" [1]
>
> DESCRIPTION: There are situations where the field or setter with an
> @callback annotation (when used to obtain a reference to a callaback
> instance) can be injected with NULL. As noted in section 8.2
> RequestContext, the getCallback() method might return NULL in certain
> situations, and those situations might also occur in combination with
> the use of @callback. For example, suppose a component implements
two
> services, one has a bidirectional interface and the other does not.
The
> component impl could use @callback to get a callback instance. When
> invoked over the bidirectional service, the @callback will non-null,
but
> will be null when the non-bidirectional service is invoked. AFAIK,
the
> specs don't prohibit the example (nor do I think they should).
>
This case isn't quite the same as RequestContext.getCallback().
In that case, the API can return NULL. In this case, the callback
would not be injected, and so the field would be uninitialized.
> PROPOSAL:
> There is no pdf for [1] so bear with me:
> In section 6.2.4, at the end of the first paragraph (line 395) add
the
> following:
>
> A field or setter method annotated with @callback might be injected
or
> set to NULL if the implementation is invoked through a non-bidirectional
> service or when invoked as a callback.
>
As I said above, it's not correct to say "...might be injected or
set to NULL...". It's really "...might not be injected...".
>
The
component implementation
> should always check for null before using a callback reference (See
also
>
You've got a non-RFC2119 "should" here. Even if we found
another
word, I think it's going too far to say that this should *always*
be done. IMO it should *only* be done if the component logic
allows this case to arise, which I believe will be a minority of
all the cases where callbacks are used.
> the getCallbackReference() method in section 8.2 "RequestContext").
>
> In section 6.2.4, the first example (line 400) replace the example
with
> the following:
>
> @Callback
> protected ServiceReference<MyCallback> callback;
>
> *public void *someMethod() {
>
> *if* (callback) {
> MyCallback myCallback = callback.getCallback();
…
>
> myCallback.receiveResult(theResult);
> }
> }
>
These changes overlap with the proposed changes for JAVA-76,
and they carry forward one of the problems that is the subject
of JAVA-76 (incorrectly using getCallback() where getService()
should be used). Also, bearing in mind my comment above, I'm
not convinced that this example needs to show the "if". I
think
it's enough to describe the possibility in added text.
Simon
>
>
> [1]
>
http://www.oasis-open.org/committees/download.php/31121/sca-javacaa-1.1-spec-cd02-rev2.doc
>
> Dave Booz
> STSM, BPM and SCA Architecture
> Co-Chair OASIS SCA-Policy TC and SCA-J TC
> "Distributed objects first, then world hunger"
> Poughkeepsie, NY (845)-435-6093 or 8-295-6093
> e-mail:
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[attachment "pic01519.jpg" deleted by Mike Edwards/UK/IBM] [attachment
"pic24194.jpg" deleted by Mike Edwards/UK/IBM] [attachment "pic03501.jpg"
deleted by Mike Edwards/UK/IBM] [attachment "pic23250.jpg" deleted
by Mike Edwards/UK/IBM] [attachment "pic24729.jpg" deleted by
Mike Edwards/UK/IBM] [attachment "pic31249.jpg" deleted by Mike
Edwards/UK/IBM] [attachment "pic28022.jpg" deleted by Mike Edwards/UK/IBM]
[attachment "pic16408.jpg" deleted by Mike Edwards/UK/IBM] [attachment
"pic30621.jpg" deleted by Mike Edwards/UK/IBM] ---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
