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

[Simon Nash <oasis@cjnash.com>]

David Booz wrote:
> 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").
> 
Apart from the question of whether or not NULL gets injected, I don't
think we should make the component implementation logic into an RFC2119
conformance target.  I'd like to proposed alternative wording that
addresses these two points:

A field or setter method annotated with @Callback will not be injected
if the implementation is invoked through a non-bidirectional service or
when invoked as a callback. To allow for this, the component implementation
can check for null before using a callback reference in this situation
(See also the getCallbackReference() method in section 8.2 "RequestContext").

   Simon

> 
> 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
> 
> Inactive hide details for Simon Nash ---02/10/2009 11:18:56 AM---David 
> Booz wrote: > TARGET: Java CAA, section 6.2.4 "AccessingSimon Nash 
> ---02/10/2009 11:18:56 AM---David Booz wrote: > TARGET: Java CAA, 
> section 6.2.4 "Accessing Callbacks" [1]
> 
> 
> From:	
> Simon Nash <oasis@cjnash.com>
> 
> To:	
> sca-j@lists.oasis-open.org
> 
> Date:	
> 02/10/2009 11:18 AM
> 
> Subject:	
> Re: [sca-j] NEW ISSUE: @Callback injection could be NULL
> 
> ------------------------------------------------------------------------
> 
> 
> 
> 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
> 
> 
> 
> ---------------------------------------------------------------------
> 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 
> 
> 
>