[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-j] ISSUE 4 - Dependency reinjection
The distinction is that an unavailable service may become available again
in the future (so retrying may be appropriate), whereas an invalid service
is gone for ever.
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
08/01/2008 09:32
To
"OASIS Java" <sca-j@lists.oasis-open.org>
cc
Subject
Re: [sca-j] ISSUE 4 - Dependency reinjection
Dave,
I suppose we could use ServiceUnavailableException.
I'm not sure that the distinction is particularly useful. The client
can't do anything really
different other than log the error using a different name.
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
David Booz <booz@us.ibm.com>
07/01/2008 15:34
To
sca-j@lists.oasis-open.org
cc
Subject
Re: [sca-j] ISSUE 4 - Dependency reinjection
Mike,
Why wouldn't we use the existing ServiceUnavailableException for your
additional case?
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"
01/07/2008 04:27 <sca-j@lists.oasis-open.org>
AM 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 | |
|------+-----------------------+-----------------------+-----------------|
| Chang| Reference | Existing | Subsequent |
| e | | ServiceReference | Invocations of |
| Event| | Object | ComponentContext|
| | | | . |
| | | | getServiceRefere|
| | | | nce() or |
| | | | cast() |
|------+-----------------------+-----------------------+-----------------|
| Chang| MAY be reinjected (if | MUST continue to work | Result |
| e to | other conditions | as if the reference | corresponds to |
| the | apply). | target was not | the injected |
| Targe| If not reinjected, | changed. | reference (i.e.|
| t of | then it MUST continue | | changed only if |
| a | to work as if the | | reinjection |
| Refer| reference target was | | occurred). |
| ence | not changed. | | |
|------+-----------------------+-----------------------+-----------------|
| Targe| Business methods | Business methods | Result SHOULD be|
| ted | SHOULD throw | SHOULD throw | a reference to |
| Servi| InvalidServiceExceptio| InvalidServiceExceptio| the undeployed |
| ce | n. | n. | service. |
| Undep| | | Business methods|
| loyed| | | SHOULD throw |
| | | | InvalidServiceEx|
| Targe| | | ception. |
| t | | | |
| Servi| | | |
| ce | | | |
| becom| | | |
| es | | | |
| Unava| | | |
| ilabl| | | |
| e | | | |
|------+-----------------------+-----------------------+-----------------|
| Targe| MAY continue to work, | MAY continue to work, | Result SHOULD be|
| ted | depending on the | depending on the | a reference to |
| Servi| runtime and the type | runtime and the type | the changed |
| ce | of change that was | of change that was | service. |
| Chang| made. If it doesn't | made. If it doesn't | |
| ed | work, the exception | work, the exception | |
| | thrown will depend on | thrown will depend on | |
| | the runtime and the | the runtime and the | |
| | cause of the failure. | cause of the failure. | |
|------+-----------------------+-----------------------+-----------------|
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: mike_edwards@uk.ibm.com
"Reza Shafii" <rshafii@bea.com>
04/01/2008 22:19 To
<sca-j@lists.oasis-ope
n.org>
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
---------------------------------------------------------------------
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]