[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-j] ISSUE 4 - Dependency reinjection
Mike, I think there is a difference of view on what is the "simpler" approach in this situation. One view of "simpler" is to have the minimum of rules. So reinjection would be allowed with all component types and the component developer would have total flexibility. This means that the component developer is responsible for understanding all the implications of making certain choices, which could give rise to problems (perhaps of a very subtle nature) if used inadvisedly. It's the last point that bothers me. We have four different scopes, so if each of them allows reinjection or not, this gives 8 combinations. The developer has to understand the implications of all 8 of these. Some combinations may not be useful or may carry subtle pitfalls, but developers needs to understand this or may make a wrong choice and get themselves into trouble. SCA doesn't help here, because all options are possible, so the developer must rely on best practices articles to provide the necessary guidance. And if it's too hard to decide, they just copy what their colleague in the next desk is doing, and hope that their circumstances and needs are the same as their colleague's. The other approach is for SCA to be more prescriptive and to rule out certain combinations because they don't make sense or have too many pitfalls. With this approach, SCA would say "These are the characteristics of a stateless component; it does this and it does that and it can't do the other", and similarly for the other scopes. The combinations of "can do" and "can't do" aren't arbitrary, but would be explained by SCA based on how the component is intended to be used. The choices of what to allow would be based on what is required to support known real world use cases. This is the alternate view of "simpler". If the limited choice turns out to be too restrictive and there's some user requirement that isn't covered, it's easy enough to relax the restrictions later without breaking compatibility. The converse doesn't apply as it's generally not possible to impose restrictions once some functionality has been allowed.. 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 08/01/2008 08:42 To "OASIS Java" <sca-j@lists.oasis-open.org> cc Subject RE: [sca-j] ISSUE 4 - Dependency reinjection Reza, I have one specific comment to make here - done inline.... 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> wrote on 07/01/2008 21:07:32: > > Another option would be to use Mike's idea of a "reinject" parameter on > @Reference to also derive the behavior of the getServiceReference() > method. If reinject="true" reinjection should occur and subsequent > invocations of getServiceReference() would lead to an object referencing > the new target. If reinject="false", reinjection should not occur and > subsequent invocations of getServiceReference() would lead to the target > prior to rewiring. > > I am also thinking that the reinject=true value would only be valid if > the conditions previously discussed apply (i.e. scope is composite, > conversational interfaces must not be active, and the reference is field > based or setter based). This would change the table as attached. This was NOT my proposal. My proposal is that IF reinject=true is set, then reinjection occurs for ANY scope of component. My thinking here is that, since by default no reinjection occurs, and that the programmer has to do something active to get reinjection to occur, then it is reasonable to allow reinjection for any and all scopes - at the request of the programmer. This gets rid of those rules that you list above. The thinking here is that IF you care about reinjection, then you will take the trouble to think through what it means to change the reference you are using (or perhaps, writers of material about SCA will take the trouble to tell you....). > > Cheers, > > Reza 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]