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

[Simon Nash <oasis@cjnash.com>]

David Booz wrote:
> My concern is with setter method injection. In your view, these setters 
> would not be driven for @callback when invoked under a non-bidi service. 
> That seems surprising to me as it feels more consistent to always drive 
> the method with whatever the reference is supposed to point to given the 
> context you're executing in. It gives a consistent FW/container behavior 
> for the developer of the component impl. I don't agree that it creates 
> the need for extra null checks in the setter. In this mixed/corner case 
> that's exactly what you'd want as the developer already knows he's 
> creating a mixed (bidi and non-bidi) situation. There might be real work 
> for him to do in the setter to prepare if there's no callback. The whole 
> point of setter injection is so that the developer can inject other 
> behavior at that point in the lifecycle. If you optimize it away, you've 
> unnecessarily and inconsistently constrained the developer.
> 
> I think Mike E is right that we should be consistent with reference 
> injection. I don't think the spec says whether or not to drive the 
> setters for multiplicity 0. I'm happy to be corrected if someone can 
> point me to spec text.
> 
This could be different depending on whether the reference is 0..1
or 0..n.  For 0..n there is something to inject - an empty array.
For 0..1, there is nothing to inject. (Not NULL, nothing.)

   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/11/2009 04:33:12 PM---David 
> Booz wrote: > I'm glad we're doing this in email, and noSimon Nash 
> ---02/11/2009 04:33:12 PM---David Booz wrote: > I'm glad we're doing 
> this in email, and not on the call. We need to do
> 
> 
> From:	
> Simon Nash <oasis@cjnash.com>
> 
> To:	
> sca-j@lists.oasis-open.org
> 
> Date:	
> 02/11/2009 04:33 PM
> 
> Subject:	
> Re: [sca-j] NEW ISSUE: @Callback injection could be NULL
> 
> ------------------------------------------------------------------------
> 
> 
> 
> 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.
>  >
> In Java, there is no such thing as an uninitialized field.  All Java
> fields have a well-defined initial value.  I see no problem with
> taking advantage of this Java language feature.
> 
> Forcing NULL to be injected could actually make things worse, not
> better.  What if the callback injection is via a setter method?
> Having the SCA runtime call the setter with NULL is asking either
> for NPEs, or for pointless defensive code inside setter methods
> to do null checks.  IMO it is better for the SCA runtime to not
> invoke these setter methods than to invoke them with NULL passed in.
> 
> What about non-required references and properties?  This seems like
> a very similar case.  We don't inject NULL for these, and I don't
> think we should.
> 
>   Simon
> 
>  > 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: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 
> 
> 
>