OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-j message

[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


A target could become NULL for more cases than undeployment. Deploying a wire could do it.

I'm really not understanding the desire to be deliberately inconsistent. It's like we're speaking past each other somehow.

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/20/2009 08:44:45 AM---David Booz wrote: > So let's focus on the re-injection case foSimon Nash ---02/20/2009 08:44:45 AM---David Booz wrote: > So let's focus on the re-injection case for setter methods. If the


From:

Simon Nash <oasis@cjnash.com>

To:

sca-j@lists.oasis-open.org

Date:

02/20/2009 08:44 AM

Subject:

Re: [sca-j] NEW ISSUE: @Callback injection could be NULL





David Booz wrote:
> So let's focus on the re-injection case for setter methods. If the
> Domain is changed such that a wire disappears (and the runtime supports
> re-injection), then wouldn't you expect a NULL to be re-injected? The
> answer has to be yes, so why then wouldn't you do the initial injection
> with NULL. I don't see why we should be inconsistent in this case either.
>
The section on reinjection (9.17.1) is very explicit that this does
not happen.  Reinjection MAY happen only for a change to the target of
the reference.  If the target service is undeployed, there is no
reinjection (of NULL or anything else).

Given the large amount of time and attention that we spent on the
resolution to this issue (JAVA-4), I think this was a deliberate choice
and I would not want to reopen it now.

  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 Jim Marino ---02/16/2009 11:37:42 AM---@Init
> and @Destroy are very important in both cases as they alJim Marino
> ---02/16/2009 11:37:42 AM---@Init and @Destroy are very important in
> both cases as they allow for initialization code to be ex
>
>
> From:
> Jim Marino <jim.marino@gmail.com>
>
> To:
> David Booz/Poughkeepsie/IBM@IBMUS
>
> Cc:
> sca-j@lists.oasis-open.org
>
> Date:
> 02/16/2009 11:37 AM
>
> Subject:
> Re: [sca-j] NEW ISSUE: @Callback injection could be NULL
>
> ------------------------------------------------------------------------
>
>
>
> @Init and @Destroy are very important in both cases as they allow for
> initialization code to be executed before a service operation is
> executed and a component to receive a container callback to perform
> cleanup respectively.
>
> If @Init were removed, it would force implementation code to handles
> these cases by inelegantly inserting an initialization method call in
> the code block of every service operation. Note the specs should not
> recommend constructors as a way to perform general initialization as the
> latter may be required to invoke another object instance.
>
> @Destroy is important for stateless components for the same reason as
> @Init: it avoids requiring implementations to insert a method call at
> the end of every service operation code block. In composite scope,
> @Destroy is important as there is no other way to receive a container
> callback when an instance is shut down.
>
> On the issue of setter injection, it's useful for the following reasons:
>
> 1. It allows for reinjection wheres CDI does not
> 2. It makes unit testing easier with respect to when protected fields
> are used for injection as testing code does not need to use reflection
> or a subclass to set mock component dependencies.
> 3. It facilitates porting component implementations to other POJO
> frameworks
> 4. Some ideologues prefer setter injection over protected fields as it
> preserves encapsulation. They would argue it is not really much typing
> as most IDEs can auto-generate setters from a field through one click
> (I'm not one of the ideologues but IntelliJ, the IDE I use, will do this).
>
> Jim
>
>
> On Feb 16, 2009, at 4:32 AM, David Booz wrote:
>
>             I have been wondering why we need @init and @destroy now
>             that we only have composite and stateless scoped components.
>
>             That aside, what's the purpose of setter injection if not to
>             allow for some init time code? It's extra work to the
>             developer for no perceived value if we take your view.
>
>             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_ <
mailto:booz@us.ibm.com>
>
>             <graycol.gif>Jim Marino ---02/13/2009 06:46:47 PM---On Feb
>             13, 2009, at 3:34 PM, Simon Nash wrote: > David Booz wrote:
>             <ecblank.gif>
>             From: <ecblank.gif>
>             Jim Marino <_jim.marino@gmail.com_
>             <
mailto:jim.marino@gmail.com>>
>             <ecblank.gif>
>             To: <ecblank.gif>
>             Simon Nash <_oasis@cjnash.com_ <
mailto:oasis@cjnash.com>>
>             <ecblank.gif>
>             Cc: <ecblank.gif>_
>             __sca-j@lists.oasis-open.org_
>             <
mailto:sca-j@lists.oasis-open.org>
>             <ecblank.gif>
>             Date: <ecblank.gif>
>             02/13/2009 06:46 PM
>             <ecblank.gif>
>             Subject: <ecblank.gif>
>             Re: [sca-j] NEW ISSUE: @Callback injection could be NULL
>
>             ------------------------------------------------------------------------
>
>
>
>
>             On Feb 13, 2009, at 3:34 PM, Simon Nash wrote:
>
>              > David Booz wrote:
>              >> I'm going to try to state this again without using the
>             word  
>              >> injection because it seems to have too many
>             connotations.....and  
>              >> the email thread is wandering all over the place.
>              >> The point I'm worried about is a setter method that is
>             annotated  
>              >> with @callback (or even a 0..1 @reference as pointed out
>             earlier).
>              >> I'm concerned that we provide a consistent model to
>             component  
>              >> developers, and therefore the runtime MUST NOT skip
>             invocation of  
>              >> the setter method. It may be very important for the
>             logic in the  
>              >> setter method to understand that there is no reference
>             target or  
>              >> callback. It's the 'skipping of the setter' that is the
>             problem.
>              > I don't think we need to drive all these setters with
>             null arguments
>              > just in case they have some important initialization to
>             do.  My reason
>              > for saying this is that we also have the @Init method,
>             which is called
>              > after all the setters have (or have not) run.
>              >
>              > So the consistent model is that all setters with
>             something to set
>              > would run, and then the @Init method would run.  This
>             combination
>              > allows the implementation code to handle all possible cases.
>              > For example, the setters could each set a flag to say
>             "OK, done my
>              > thing", and the @Init method could check these flags to
>             find out
>              > if further processing is needed because some setter did
>             not run.
>              >
>             FWIW, I prefer the approach of using the @Init method. A
>             strong  
>             argument can be made that setters should not be performing  
>             initialization logic - a setter should just set a value and
>             @Init  
>             should be used for initialization Sticking to this rule has
>             the nice  
>             effect of keeping setters simple and clean (i.e. no need for
>             null  
>             checks) and consolidating initialization in one place where it  
>             arguably should be. Also, from an implementation
>             perspective, less  
>             invocations to set items increases performance. Of course the  
>             exception is CDI in the case where a reference is optional,
>             but that  
>             is probably a very specific use-case.
>
>
>              > I was looking to see what Spring does.  AFAICT it does
>             not drive
>              > dependency injection setters when the dependency is
>             missing (though
>              > it does pass NULL for missing dependencies when calling
>             constructors).
>              > See this article:
>              >
>             _http://blog.springsource.com/2007/07/11/setter-injection-versus-constructor-injection-and-the-use-of-required/_
>              > The article also mentions the @Init-style approach that I
>             described
>              > above as one way to check for missing dependencies.
>              >
>              >  Simon
>              >
>              >> The spec text you point out does not clearly say what to
>             do. The  
>              >> text is clearly written assuming everything is wired up
>             (I'm guilty  
>              >> of thinking that way myself).
>              >> 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_ <
mailto:booz@us.ibm.com>
>              >> Inactive hide details for Simon Nash ---02/13/2009
>             09:41:55 AM---
>              >> David Booz wrote: > I'm glad we're doing this in email,
>             and noSimon  
>              >> Nash ---02/13/2009 09:41:55 AM---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_ <
mailto:oasis@cjnash.com>>
>              >> To:
>              >> _sca-j@lists.oasis-open.org_
>             <
mailto:sca-j@lists.oasis-open.org>
>              >> Date:
>              >> 02/13/2009 09:41 AM
>              >> 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_ <
mailto: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_ <
mailto:oasis@cjnash.com>>
>              >> >
>              >> > To:
>              >> > _sca-j@lists.oasis-open.org_
>             <
mailto: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_ <
mailto: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
>              >
>              >
>              >
>              >
>             ---------------------------------------------------------------------
>              > 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_
>
>
>
>



---------------------------------------------------------------------
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]