[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-j] NEW ISSUE: @Callback injection could be NULL
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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]