Re: [sca-j] NEW ISSUE: @Callback injection could be NULL

[Simon Nash <oasis@cjnash.com>]

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:booz@us.ibm.com