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