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

[Jim Marino <jim.marino@gmail.com>]

Hi,

Quick question inline....

Jim

On Feb 13, 2009, at 6:39 AM, Simon Nash wrote:

> 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").
>

What happens for methods that exist both on the forward bidirectional  
interface and another, "unidirectional" interface?

>  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
>
>
>
> ---------------------------------------------------------------------
> 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