The rationale is to keep the number of
components that have to deal with the complexity of references changing in the
middle of their lifetime to a minimum. Since I think that composite-scoped
components live indefinitely, it is especially important that they handle
reinjection. Conversation-scoped components are likely not to live much more
than a few weeks (IMO), so a runtime could change over the wire target only as
conversational-scoped components go out of scope.
That was the rationale, although after
writing this I had second thoughts, for exactly the reasons you mention. I
could easily imagine allowing reinjection for both composite and conversational
scoped components.
Michael
From: Mike
Edwards [mailto:mike_edwards@uk.ibm.com]
Sent: Tuesday, December 04, 2007
10:23 AM
To: OASIS Java
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