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

[David Booz <booz@us.ibm.com>]

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.

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

Simon 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