[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
C Vamsi wrote:
> 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?
>
I think it's a design error as well, though I would like to slightly
reword Vamsi's question as "What does it mean when a method from a
non-bidirectional service is looking to use an *injected* callback?"
The difference is that it can be valid for a callback to be injected
when a bidi service is called, stored away for later use, and used
some time later by a call from a non-bidi service.
Simon
> ++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
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> 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]