RE: [sca-j] ISSUE 4 - Dependency reinjection

[David Booz <booz@us.ibm.com>]

Michael,

And tagging on a few more questions:

1) I presume that the use of setter based injection would allow for
concurrency serialization by the component implementation so that it could
stabilize it's use of references.  This brings up an interesting question;
is there (or should there be) some linkage between the lifecycle of the
target service and these references?  Just because a ref target has been
altered, does not mean that the target service is gone.  It's the lifecycle
of that target service which will determine how long a reference remains
usable after a wiring change occurs.  Just raising the question for now
because it will affect all the component's whose references can't be
re-injected.

2) I'm curious about your introduction of InvalidServiceException.  We
already have ServiceUnavailableException.  I think there's room to clarify
the wording of SUE to make room for ISE.

3) +1 to Mike E.


Dave Booz
STSM, SCA and WebSphere Architecture
Co-Chair OASIS SCA-Policy TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093  or  8-295-6093
e-mail:booz@us.ibm.com
http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome


                                                                           
             Mike Edwards                                                  
             <mike_edwards@uk.                                             
             ibm.com>                                                   To 
                                       "OASIS Java"                        
             12/04/2007 10:22          <sca-j@lists.oasis-open.org>        
             AM                                                         cc 
                                                                           
                                                                   Subject 
                                       RE: [sca-j] ISSUE 4 - Dependency    
                                       reinjection                         
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           





Michael,

Thanks for the proposal.  It is good to have something concrete as it help
crystallise the
issues.

Please help me understand the rationale for treating Composite-scoped
components
differently from Conversation scoped components.

Both types of component have an extended lifecycle.  Both may easily have a
lifecycle
that spans changes in configuration that affects their references, even
where those
references are not conversational and do not in themselves involve some
extended
lifetime.  Why is it justified to change references in the one case and not
allow changes
in the other case?


Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431
Email:  mike_edwards@uk.ibm.com

"Michael Rowley" <mrowley@bea.com> wrote on 29/11/2007 20:19:28:

>
> I took an action item to make a more specific proposal for
> dependency reinjection.  Here it is:
>
> Reinjection
> -----------
>
> References MAY be reinjected after the initial creation of a
> component due to a change in wiring that has occurred since the
> component was initialized.  In order for reinjection to occur, the
> following MUST be true:
> - The component MUST be composite-scoped.
> - The reference MUST use either field-based injection or setter
> injection.  References that are injected through constructor
> injection MUST NOT be changed.
> - If the reference has a conversational interface, then a
> conversation MUST NOT be active at the time of the reinjection.
>
> If processing in reaction to a change in a reference is necessary,
> then setter injection should be used, with code in the setter method
> that does the proper processing in reaction to a change.
>
> Components with any scope other than the composite scope MUST NOT
> have references reinjected.  If an operation is called on a
> reference where the target of that reference is no longer valid,
> then InvalidServiceException MUST be thrown.
>
> In cases where changes to a reference are not valid, the reference
> as accessed through the component context also MUST NOT change.
> More precisely, the ComponentContext.getService() and
> getServiceReference() methods MUST return the same reference target
> as would be accessed through injection.  However, the
> ServiceReference that is returned by getServiceReference() never
> changes its target.  If the wiring of a composite component causes a
> reference to be reinjected, any ServiceReference object that was
> acquired before the reinjection will still correspond to the target
> prior to the change.  If the target service for a ServiceReference
> ever becomes invalid, then attempts to call business methods through
> that ServiceReference MUST throw InvalidServiceException.
>
> The rules for reference reinjection also apply to references with a
> 0..N or 1..N.  This means that in the cases listed above where
> reference reinjection is not allowed, the array or Collection for
> the reference MUST NOT change their contents.  In cases where the
> contents of a reference collection MAY change, then for references
> that use setter injection, the setter method MUST be called for any
> change to the contents.  The injected collection MAY be the same
> collection object as is currently used by the component, but with
> some change to its contents.
>
> Michael







Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU