[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:
> A target could become NULL for more cases than undeployment. Deploying a
> wire could do it.
>
How does deploying a wire make a non-null target null, unless
something is undeployed?
> I'm really not understanding the desire to be deliberately inconsistent.
> It's like we're speaking past each other somehow.
>
I think our view of consistency is different. Driving a setter
when there is nothing to set feels inconsistent to me.
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/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]