Simon,

Yes, you're right - I had a small brainstorm when making my original comments about getService() - I think that getService and getServiceReference() must be identical in terms of the reference wiring they return - and I agree that they should always return the latest wiring.

If a component wants to continue using the "old wiring", then what the component must do is to store the reference proxy for the original wiring somewhere and continue to use it when invoking operations. The proxy should be guaranteed not to change in terms of its wiring - the wiring may be invalidated (at the choice of the runtime - meaning that subsequent invocations fail with an exception) but it cannot be changed silently "under the covers" to point to somwhere new.

My thought is then to allow reinjection of a reference via a setter method for any scope of component where the component marks the reference with reinject="true". The calling of the setter method then acts as a signal to the component that the wiring has changed, along with a new reference proxy that represents the new wiring. The component can decide whether or not to use the new reference proxy at its own choosing.

Note that I am now thinking that reinjection of a Field is not a good idea - there is no easy way for the component to know that the change has taken place.

If the component uses the alternative approach of using getService() or getServiceReference(), then the component needs to be made aware of the fact that it may get back different reference proxy objects for each subsequent invocation - and these may represent different wiring. To avoid unexpected changes, the component should store and use the returned proxy. The returned proxy always reflects the "current" Domain configuration at the time the method is invoked.

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

Simon Nash/UK/IBM@IBMGB To "OASIS Java" <sca...@lists.oasis-open.org> cc 09/01/2008 12:18 Subject RE: [sca-j] ISSUE 4 - Dependency reinjection

Mike, The getService() method is defined as follows: getService(Class<B> businessInterface, String referenceName) ? Returns a proxy for the reference defined by the current component. This could be afftected by rewiring without redeployment.

The comments from various folks including Reza, Henning, Dave and Mike are making me think that the only consistent way to handle API calls is to make them always use the most current wiring (except for cast, which operates on an existing proxy). This would change the top right box of Reza's table.

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 09/01/2008 10:45

To "OASIS Java" <sca...@lists.oasis-open.org> cc

Subject RE: [sca-j] ISSUE 4 - Dependency reinjection

Dave,

Some of these literally can't occur, in my opinion - details follow.

Basically, my view is that if a component gets redeployed (ie original configuration is undeployed and a new configuration is deployed), then this is something completely new - there is no question of "updating" any instances of components of the old configuration.

I suppose there is a question of whether the pre-existing component instances are allowed to remain in existence when a redeployment of this kind takes place. I'm prepared to punt on this for now and leave it up to the runtime.

For me, redeployment of a component never creates reinjection of the component instances belonging to the old configuration.

Note that this is different from the case of references - as I pointed out previously, the wiring and the target service(s) of a reference can change WITHOUT redeployment of the component itself. In this case, redeployment can occur either on separately deployed wire elements and/or on target components that are separately deployed. So there are special measures required in these cases, which is what we have been debating.

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

David Booz <bo...@us.ibm.com> 08/01/2008 20:46

To sca...@lists.oasis-open.org cc

Subject RE: [sca-j] ISSUE 4 - Dependency reinjection

This thread is wandering around on various topics. I explicitly picked this part of the thread to make an additional point.

The proposal needs to consider all the APIs: (a) getURI() - A deployment change could affect what is returned

<mje> This can only happen with a redeployment, I think. </mje>

(b) getService() - Wiring could affect what is returned here

<mje> I'm not sure what changes you're implying here. Typically, IF wiring is deployed separately from the component, then it CAN'T affect the service. It CAN affect reference targets.</mje>

(c) createSelfReference() - A deployment change to the component itself could affect what's returned here

<mje> Clearly, this is a redeployment of the component itself </mje>

(d) getProperty() - I don't know why we're limiting the re-injection issue to references

<mje> Properties can only get changed if the component, or its containing composite, is itself redeployed. </mje>

It is not wise to have some of the CC API's expose wiring or deployment changes, but not others.

Dave Booz STSM, SCA and WebSphere Architecture Co-Chair OASIS SCA-Policy TC "Distributed objects first, then world hunger" Poughkeepsie, NY (845)-435-6093 or 8-295-6093 e-mail:bo...@us.ibm.com http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome

Simon Nash <NA...@uk.ibm.com> To 01/07/2008 01:48 "OASIS Java" PM <sca...@lists.oasis-open.org> cc

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

To Simon Nash/UK/IBM@IBMGB, "OASIS Java" <sca...@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:NA...@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...@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...@uk.ibm.com

"Reza Shafii" <rsha...@bea.com> 04/01/2008 22:19

To <sca...@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

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

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

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