[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
I think it is a design error. What does it mean when a method from a non-bidirectional service is looking to use a callback? ++Vamsi Apache Tuscany Committer http://tuscany.apache.org Apache Geronimo Committer and Member of PMC http://geronimo.apache.org David Booz <booz@us.ibm.com> To 12/02/2009 00:42 sca-j@lists.oasis-open.org cc Subject Re: [sca-j] NEW ISSUE: @Callback injection could be NULL Depends what you mean by an error. It is not necessarily a design error, but it is a coding error if you don't check for null. This is also possible through EJBs, but it can happen within implementation.java as well. 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 (Embedded image moved to file: pic10358.jpg)C Vamsi ---02/11/2009 11:07:24 AM---If a component is providing both bidirectional and non-bidirectional services isn't it an error in i (Embedde (Embedded image moved to file: pic30175.jpg) d image C Vamsi <vamsic007@in.ibm.com> moved to file: pic13100 .jpg) From: (Embedde (Embedded image moved to file: pic20052.jpg) d image David Booz/Poughkeepsie/IBM@IBMUS moved to file: pic05743 .jpg) To: (Embedde (Embedded image moved to file: pic26230.jpg) d image sca-j@lists.oasis-open.org moved to file: pic20564 .jpg) Cc: (Embedde (Embedded image moved to file: pic04370.jpg) d image 02/11/2009 11:07 AM moved to file: pic29281 .jpg) Date: (Embedde (Embedded image moved to file: pic10887.jpg) d image Re: [sca-j] NEW ISSUE: @Callback injection could be NULL moved to file: pic00587 .jpg) Subject: If a component is providing both bidirectional and non-bidirectional services isn't it an error in implementation if a method from non-bidirectional service is using a callback? Also, a method from bidirectional service would expect access to a callback service and if the callback service is not available, it may not be able to serve the request. This situation of NULL callback may not arise when bidirectional service is invoked through SCA mechanism, as the interface of service and reference will have to match. (One of the situations I see is with EJBs providing bidirectional services. What should happen when the EJB is invoked as an EJB, not as an SCA service is out of the scope of the current discussion I guess.) ++Vamsi Apache Tuscany Committer http://tuscany.apache.org Apache Geronimo Committer and Member of PMC http://geronimo.apache.org David Booz <booz@us.ibm.com> To 11/02/2009 20:12 sca-j@lists.oasis-open.org cc Subject Re: [sca-j] NEW ISSUE: @Callback injection could be NULL 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"). 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 (Embedded image moved to file: pic01519.jpg)Simon Nash ---02/10/2009 11:18:56 AM---David Booz wrote: > TARGET: Java CAA, section 6.2.4 "Accessing Callbacks" [1] (Embedde (Embedded image moved to file: pic03501.jpg) d image Simon Nash <oasis@cjnash.com> moved to file: pic24194 .jpg) From: (Embedde (Embedded image moved to file: pic24729.jpg) d image sca-j@lists.oasis-open.org moved to file: pic23250 .jpg) To: (Embedde (Embedded image moved to file: pic28022.jpg) d image 02/10/2009 11:18 AM moved to file: pic31249 .jpg) Date: (Embedde (Embedded image moved to file: pic30621.jpg) d image Re: [sca-j] NEW ISSUE: @Callback injection could be NULL moved to file: pic16408 .jpg) Subject: 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 (See attached file: pic01519.jpg)(See attached file: pic24194.jpg)(See attached file: pic03501.jpg)(See attached file: pic23250.jpg)(See attached file: pic24729.jpg)(See attached file: pic31249.jpg)(See attached file: pic28022.jpg)(See attached file: pic16408.jpg)(See attached file: pic30621.jpg) --------------------------------------------------------------------- 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 (See attached file: pic01519.jpg)(See attached file: pic24194.jpg)(See attached file: pic03501.jpg)(See attached file: pic23250.jpg)(See attached file: pic24729.jpg)(See attached file: pic31249.jpg)(See attached file: pic28022.jpg)(See attached file: pic16408.jpg)(See attached file: pic30621.jpg) --------------------------------------------------------------------- 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]