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:]
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:
"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
