Dave,
Some of these literally can't occur,
in my opinion - details follow.
Basically, my view is that if a component
gets redeployed (ie original configuration is undeployed
and a new configuration is deployed),
then this is something completely new - there is no question
of "updating" any instances
of components of the old configuration.
I suppose there is a question of whether
the pre-existing component instances are allowed to remain
in existence when a redeployment of
this kind takes place. I'm prepared to punt on this for now and
leave it up to the runtime.
For me, redeployment of a component
never creates reinjection of the component instances belonging
to the old configuration.
Note that this is different from the
case of references - as I pointed out previously, the wiring and the
target service(s) of a reference can
change WITHOUT redeployment of the component itself. In this
case, redeployment can occur either
on separately deployed wire elements and/or on target components
that are separately deployed. So
there are special measures required in these cases, which is what we
have been debating.
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 <>
08/01/2008 20:46
To
cc
Subject
RE: [sca-j] ISSUE 4 - Dependency reinjection
This thread is wandering around on various topics.
I explicitly picked
this part of the thread to make an additional point.
The proposal needs to consider all the APIs:
(a) getURI() - A deployment change could affect what is returned
<mje> This can only
happen with a redeployment, I think. </mje>
(b) getService() - Wiring could affect what is returned here
<mje> I'm not sure
what changes you're implying here. Typically, IF wiring is deployed
separately from the component,
then it CAN'T affect the service. It CAN affect reference
targets.</mje>
(c) createSelfReference() - A deployment change to the component itself
could affect what's returned here
<mje> Clearly, this
is a redeployment of the component itself </mje>
(d) getProperty() - I don't know why we're limiting the re-injection issue
to references
<mje> Properties
can only get changed if the component, or its containing composite, is
itself redeployed.
</mje>
It is not wise to have some of the CC API's expose wiring or deployment
changes, but not others.
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
Simon Nash
<>
To
01/07/2008 01:48
"OASIS Java"
PM
<>
cc
Subject
RE: [sca-j]
ISSUE 4 - Dependency
reinjection
Reza,
My first thought was to propose what you have said. My second thought
was
that if an existing instance has not had the new target reinjected, it
could produce confusing results if calls to the reference using
ComponentContext.getServiceReference() use a target that's different from
any target currently known to the instance or available by other means.
I'll be interested to hear whether others think my first thought or second
thought was better.
Simon
Simon C. Nash, IBM Distinguished Engineer
Member of the IBM Academy of Technology
Tel. +44-1962-815156 Fax +44-1962-818999
"Reza Shafii" <>
07/01/2008 17:23
To
Simon Nash/UK/IBM@IBMGB, "OASIS Java" <>
cc
Subject
RE: [sca-j] ISSUE 4 - Dependency reinjection
Thanks Simon,
Along the same line of thought, shouldn't the effect of a "change
to the
target reference" on "subsequent invocations of getServiceReference()"
be a reference to the new target no matter whether reinjection has
occurred or not?
Cheers...
Reza
-----Original Message-----
From: Simon Nash [mailto:]
Sent: Monday, January 07, 2008 4:59 AM
To: OASIS Java
Subject: Re: [sca-j] ISSUE 4 - Dependency reinjection
Reza,
This table is very helpful. I have one comment. In the third
column,
you
have equated getServiceReference() and cast(). I don't think these
are
equivalent. getServiceReference() is obtaining a new reference, in
which
case I think the current wiring and target service should be used.
cast()
is converting an existing proxy to a ServiceReference, and I think the
semantics for this should match the semantics of using the proxy.
Here's
my attempt to capture this in tabular form.
Effect on
Change Event
Reference
Existing ServiceReference Object
Subsequent Invocations of ComponentContext.cast()
Subsequent Invocations of ComponentContext.
getServiceReference()
Change to the Target of a Reference
MAY be reinjected (if other conditions apply).
If not reinjected, then it MUST continue to work as if the reference
target was not changed.
MUST continue to work as if the reference target was not changed.
Result corresponds to the injected
reference (i.e. changed only if
reinjection occurred).
Result corresponds to the injected
reference (i.e. changed only if
reinjection occurred).
Targeted Service Undeployed
Target Service becomes Unavailable
Business methods SHOULD throw InvalidServiceException.
Business methods SHOULD throw InvalidServiceException.
Result SHOULD be a reference to the undeployed or unavailable service.
Business methods SHOULD throw InvalidServiceException.
Result SHOULD be a reference to the undeployed or unavailable service.
Business methods SHOULD throw InvalidServiceException.
Targeted Service Changed
MAY continue to work, depending on the runtime and the type of change
that
was made. If it doesn't work, the exception thrown will depend on the
runtime and the cause of the failure.
MAY continue to work, depending on the runtime and the type of change
that
was made. If it doesn't work, the exception thrown will depend on the
runtime and the cause of the failure.
MAY continue to work, depending on the runtime and the type of change
that
was made. If it doesn't work, the exception thrown will depend on the
runtime and the cause of the failure.
Result SHOULD be a reference to the changed service.
Mike,
I don't agree that re-injection should be supported for all scopes. (I
presume you are proposing that if a runtime supports it at all, then it
must be supported for all scopes.) Locating and updating existing
short-lived instances when rewiring occurs would impose runtime
overheads
without providing useful value. The annotation is an interesting
idea,
but I think it should be additive to the scope restrictions already
agreed.
Simon
Simon C. Nash, IBM Distinguished Engineer
Member of the IBM Academy of Technology
Tel. +44-1962-815156 Fax +44-1962-818999
Mike Edwards/UK/IBM@IBMGB
07/01/2008 09:27
To
"OASIS Java" <>
cc
Subject
Re: [sca-j] ISSUE 4 - Dependency reinjection
Reza,
This is a good contribution to settling this item of work.
I suggest one addition to the table - "Target Service Undeployed"
is OK
for services within the SCA Domain - to deal with services elsewhere,
"Target Service becomes Unavailable" is a better description
(we don't
know anything about HOW it became unavailable), but the effects are the
same.
Effect on
Change Event
Reference
Existing ServiceReference Object
Subsequent Invocations of ComponentContext.
getServiceReference() or
cast()
Change to the Target of a Reference
MAY be reinjected (if other conditions apply).
If not reinjected, then it MUST continue to work as if the reference
target was not changed.
MUST continue to work as if the reference target was not changed.
Result corresponds to the injected
reference (i.e. changed only if
reinjection occurred).
Targeted Service Undeployed
Target Service becomes Unavailable
Business methods SHOULD throw InvalidServiceException.
Business methods SHOULD throw InvalidServiceException.
Result SHOULD be a reference to the undeployed service. Business methods
SHOULD throw InvalidServiceException.
Targeted Service Changed
MAY continue to work, depending on the runtime and the type of change
that
was made. If it doesn't work, the exception thrown will depend on the
runtime and the cause of the failure.
MAY continue to work, depending on the runtime and the type of change
that
was made. If it doesn't work, the exception thrown will depend on the
runtime and the cause of the failure.
Result SHOULD be a reference to the changed service.
Now, I'd like to propose the following, which I realize changes some of
the decisions we made previously, but I am getting concerned about
complexity:
1. No reinjection of references occurs by default for any component of
any
scope
2. Any component of any scope can declare that it requires reinjection.
My
suggestion is to provide a parameter to the @Reference
annotation reinject="true", which only has meaning for References
which
are a) Fields b) accessible via a setter method (ie it cannot apply to
a
reference injected via the constructor).
This I believe is much simpler and it gives the component writer a
chance
to decide for themselves whether they want to be concerned about
wiring changes occurring dynamically during the lifetime of a component.
It will also make it simpler for us to give a good description of the
kinds of circumstance in which it might be good to react to wiring
changes.
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:
"Reza Shafii" <>
04/01/2008 22:19
To
<>
cc
Subject
[sca-j] ISSUE 4 - Dependency reinjection
Hi All,
In an effort to try to put more structure around a potential solution to
issue 4, Michael and I put together the attached table. Most of the
content is derived from conlusions reached by the TC's past discussions.
A
matrix such as this might help us better focus future discussions.
Looking forward to your feedback,
Reza
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries
and affiliated
entities, that may be confidential, proprietary, copyrighted
and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by
email and then delete it.[attachment "Dynamic Modification Behavior.xls"
deleted by Mike Edwards/UK/IBM]
---------------------------------------------------------------------
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
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
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries
and affiliated
entities, that may be confidential, proprietary, copyrighted
and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by
email and then delete it.
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
---------------------------------------------------------------------
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
