OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-j message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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" <rshafii@bea.com> 
07/01/2008 17:23

To
Simon Nash/UK/IBM@IBMGB, "OASIS Java" <sca-j@lists.oasis-open.org>
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:NASH@uk.ibm.com] 
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" <sca-j@lists.oasis-open.org>
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:  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







---------------------------------------------------------------------
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








[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]