HI,
Just to comment on " Targeted
Service Undeployed " usecase. According to the OSOA errata submitted in OASIS, unwired references
should have the following representation :
"An unwired reference with a
multiplicity of 0..1 must be null. An unwired reference with a multiplicity of
0..N must be an empty array or collection"
So perhaps the following
representation looks more consistent to that decision :
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:]
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:]
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
