Folks,
Controlling whether reinjection is allowed
AT ALL for a component is relatively simple in
my opinion:
- if a component does not want reference
reinjection to occur, ever, then the implementation
simply declares the reference annotation
on a constructor parameter and does not
provide the reference via either a field
or via a setter method. If the reference is only
injectable via the constructor then
it can never be changed by the container.
This simple design choice allows complete
control by the developer of the implementation.
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:
David Booz <>
05/12/2007 02:37
To
cc
Subject
RE: [sca-j] ISSUE 4 - Dependency reinjection
It's simple, just not well expressed. I'm wondering
if there are cases
where a component implementation might want to delay or "opt out"
of
re-injection either permanently or temporarily. There might be cases
where
a particular component implementation really can't tolerate a re-injection.
I was thinking out loud about using concurrency control as a temporary
means to delay re-injection. There are other ways. Maybe a different
approach like an annotation @AllowsReinjection (or the opposite) is
sufficient.
I understand that what you are proposing is optional for a runtime to
support, but for those runtimes that do support it, each component
implementation might need to have a say in how it works. Still thinking
out loud....
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:
http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome
"Michael Rowley"
<>
To
12/04/2007 08:11
David Booz/Poughkeepsie/IBM@IBMUS,
PM
<>
cc
Subject
RE: [sca-j]
ISSUE 4 - Dependency
reinjection
-----Original Message-----
From: David Booz [mailto:]
Sent: Tuesday, December 04, 2007 3:06 PM
To:
Subject: RE: [sca-j] ISSUE 4 - Dependency reinjection
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"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:
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 <>
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:
"Michael Rowley" <>
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
---------------------------------------------------------------------
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
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
