atom feed28 messages in org.oasis-open.lists.sca-jRE: [sca-j] ISSUE 4 - Dependency rein...
FromSent OnAttachments
Michael RowleySep 25, 2007 3:31 pm 
Barack, RonOct 4, 2007 2:30 am 
Michael RowleyOct 4, 2007 6:30 am 
Peshev, PeterOct 5, 2007 12:12 am 
Simon NashNov 1, 2007 10:13 am 
Blohm, HenningNov 1, 2007 11:15 am 
Simon NashNov 2, 2007 3:17 am 
Mike EdwardsNov 5, 2007 2:46 am 
Michael RowleyNov 29, 2007 12:19 pm 
Peshev, PeterNov 29, 2007 1:31 pm 
Michael RowleyNov 30, 2007 4:45 pm 
Mike EdwardsDec 4, 2007 7:22 am 
David BoozDec 4, 2007 12:59 pm 
Michael RowleyDec 4, 2007 5:07 pm 
Michael RowleyDec 4, 2007 5:11 pm 
David BoozDec 4, 2007 6:37 pm 
Mike EdwardsDec 5, 2007 1:52 am 
Mike EdwardsDec 5, 2007 1:58 am 
David BoozDec 5, 2007 5:35 am 
Mike EdwardsDec 5, 2007 5:57 am 
Blohm, HenningDec 5, 2007 7:05 am 
Peshev, PeterDec 6, 2007 1:05 am 
Michael RowleyDec 6, 2007 5:18 am 
Mike EdwardsDec 6, 2007 9:07 am 
Peshev, PeterDec 7, 2007 12:58 am 
Peshev, PeterDec 7, 2007 2:29 am 
Michael RowleyDec 7, 2007 7:55 am 
Mike EdwardsDec 7, 2007 8:50 am 
Subject:RE: [sca-j] ISSUE 4 - Dependency reinjection
From:Michael Rowley (mrow@bea.com)
Date:Dec 4, 2007 5:07:37 pm
List:org.oasis-open.lists.sca-j

The rationale is to keep the number of components that have to deal with the complexity of references changing in the middle of their lifetime to a minimum. Since I think that composite-scoped components live indefinitely, it is especially important that they handle reinjection. Conversation-scoped components are likely not to live much more than a few weeks (IMO), so a runtime could change over the wire target only as conversational-scoped components go out of scope.

That was the rationale, although after writing this I had second thoughts, for exactly the reasons you mention. I could easily imagine allowing reinjection for both composite and conversational scoped components.

Michael

------------------------------------------------------------------------------

From: Mike Edwards [mailto:mike@uk.ibm.com] Sent: Tuesday, December 04, 2007 10:23 AM To: OASIS Java Subject: RE: [sca-j] ISSUE 4 - Dependency reinjection

Michael,

Thanks for the proposal. It is good to have something concrete as it help crystallise the issues.

Please help me understand the rationale for treating Composite-scoped components differently from Conversation scoped components.

Both types of component have an extended lifecycle. Both may easily have a lifecycle that spans changes in configuration that affects their references, even where those references are not conversational and do not in themselves involve some extended lifetime. Why is it justified to change references in the one case and not allow changes in the other case?

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@uk.ibm.com

I took an action item to make a more specific proposal for dependency reinjection. Here it is:

Reinjection

-----------

References MAY be reinjected after the initial creation of a component due to a change in wiring that has occurred since the component was initialized. In order for reinjection to occur, the following MUST be true: - The component MUST be composite-scoped. - The reference MUST use either field-based injection or setter injection. References that are injected through constructor injection MUST NOT be changed. - If the reference has a conversational interface, then a conversation MUST NOT be active at the time of the reinjection.

If processing in reaction to a change in a reference is necessary, then setter injection should be used, with code in the setter method that does the proper processing in reaction to a change.

Components with any scope other than the composite scope MUST NOT have references reinjected. If an operation is called on a reference where the target of that reference is no longer valid, then InvalidServiceException MUST be thrown.

In cases where changes to a reference are not valid, the reference as accessed through the component context also MUST NOT change. More precisely, the ComponentContext.getService() and getServiceReference() methods MUST return the same reference target as would be accessed through injection. However, the ServiceReference that is returned by getServiceReference() never changes its target. If the wiring of a composite component causes a reference to be reinjected, any ServiceReference object that was acquired before the reinjection will still correspond to the target prior to the change. If the target service for a ServiceReference ever becomes invalid, then attempts to call business methods through that ServiceReference MUST throw InvalidServiceException.

The rules for reference reinjection also apply to references with a 0..N or 1..N. This means that in the cases listed above where reference reinjection is not allowed, the array or Collection for the reference MUST NOT change their contents. In cases where the contents of a reference collection MAY change, then for references that use setter injection, the setter method MUST be called for any change to the contents. The injected collection MAY be the same collection object as is currently used by the component, but with some change to its contents.

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