[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-j] ISSUE 4 - Dependency reinjection
"Peshev, Peter"
<peter.peshev@sap.com>
07/01/2008 18:18 |
|
Effect on
| |||
Change Event
|
Reference
|
Existing ServiceReference
Object
|
Subsequent Invocations of
ComponentContext.
getServiceReference() |
Targeted Service Undeployed | Reinjection with null /empty collection MAY occur | Business methods SHOULD throw ServiceUnavialbleException. | Returns null or empty collection |
I would personally would be happy to revisit that
decision and say that the "null representation" is not valid for domain level
wiring that is subject to change and keep the exception throwing as defined by
Reza.
Best Regards
Peter
________________________________
From: Blohm, Henning
[mailto:henning.blohm@sap.com]
Sent:
Monday, 7. January 2008 19:43
To: Mike Edwards; OASIS Java
Subject: AW:
[sca-j] ISSUE 4 - Dependency reinjection
Hi Reza,
Mike,
I am sure that table helps a lot. I believe the component
context should always reflect the most current wiring situation (independent of
whether re-injection occured or not). That is easiest to understand and
implement and otherwise there would be no way of getting to the current wiring
(while hoilding on to a service reference is always possible).
It
seems that less re-injection is probably safer than more re-injection, so
designating an annotation attribute looks like a smart
move.
Thanks,
Henning
________________________________
Von:
Mike Edwards [mailto:mike_edwards@uk.ibm.com]
Gesendet: Montag, 7. Januar 2008 10:27
An: OASIS Java
Betreff:
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: mike_edwards@uk.ibm.com
"Reza
Shafii" <rshafii@bea.com>
04/01/2008 22:19
To
<sca-j@lists.oasis-open.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
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]