[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-j] ISSUE 4 - Dependency reinjection
|
-----Original Message----- 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. [MR: I’m sorry, but I don’t
follow you.] 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. [MR: I think that a service that has been
correctly identified, but isn’t currently available is quite different
from a service that is incorrectly identified (it isn’t in the logical
domain). As such, I think it deserves a different exception.] 3) +1 to Mike E. [MR: No objection from me.] Michael Dave Booz STSM, SCA and WebSphere Architecture Co-Chair OASIS SCA-Policy TC "Distributed objects first, then world
hunger" 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. Phone & FAX: +44-1962-818014 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 741598. Registered office: --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the
OASIS TC that generates this mail. You may a link to this group and
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]