[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: > 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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]