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