Peter,

Thanks for the comments.

Responses inline...

-----Original Message----- From: Peshev, Peter [mailto:pete...@sap.com] Sent: Thursday, November 29, 2007 4:32 PM To: Michael Rowley; sca...@lists.oasis-open.org Subject: RE: [sca-j] ISSUE 4 - Dependency reinjection

Hi Michael,

A couple of comments

1) Like stated on the call I would disagree to the idea:

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

Suppose there is a wiring between A and B, the administrator undeploys

the wire (only the wire) and deploys a new one from A to C however if

the component implementation has stored somewhere in private field the

reference value it will continue to have access to B forever (since A

is composite scoped), regardless of what the administrator did, which at

least to me is strange. In addition an administrator will never be sure

what is going to happen without having a look at the code (is this

component caching the reference, or not)

<MR>I believe that one of the reasons why someone might want to hold a service

reference is to have a stable target that will not change if the wiring changes.

So, if the developer is explicitly trying to hold onto a target even when the

deployer does some rewiring, then the deployer should not try to prevent them.

If the developer wants to have a representation that _will_ see rewiring made

by the deployer, he or she should hold onto the component context, and get the

reference every time.</MR>

2) The proposal doesn't cover the conversational / request scoped

components when there is no reinjection, however the reference target

changes (not becomes invalid). (Assembler undeploys a wire and deploys

another one).

I would prefer that in case such component calls its reference, than the

current value of the wire should (or at least may) be provided, but I

sense you would disagree to it.

<MR>You are right that I disagree. If a reference is _not_ reinjected, then

it means (IMO) that the reference target does not change. I believe that any

time the target might change, the developer has to be aware of it and may have

to include code in a setter method that handles any ramifications of such a

change.

However, I am having some second thoughts about disallowing reinjection for

conversational-scoped components, since some conversations could last for a

very long time. I'd be interested to hear other people's opinions on that.

</MR>

3) It should be clarified what should happen in case the component is

composite-scoped, however the rule that there is no active conversation

on the reference is not fulfilled. Should the reference be reinjected

once the conversation ends ?

<MR> I would say that the reference _may_ be reinjected once the conversation

ends. I thought that was implied, but I wouldn't mind making it clearer.</MR>

4) Another minor comment is that the first paragraph says reinjection

is either field-based or setter based and later in the collection use

case we talk only about setter based reinjection.

<MR>Right. That was on purpose. The relevant sentences are:

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.

If a reference uses field injection rather than setter injection, then I don't

think there is anything more to say.

</MR>

5) Not that much relevant to this issue, but speaking of composite

scoped object participating in conversations, the spec also mentions the

annotation @ConversationId. Do you think it needs to be reinjected as

well, depending from which conversation the component is being invoked ?

<MR>The conversation id that would be injected for that is for the conversation

with the client, not for conversations through references. The conversation id

with the client should never change.</MR>

Michael

Best Regards

Peter

________________________________

From: Michael Rowley [mailto:mrow...@bea.com]

Sent: Thursday, 29. November 2007 22:19

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

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

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.

Michael

________________________________

From: Barack, Ron [mailto:ron....@sap.com]

Sent: Thursday, October 04, 2007 5:27 AM

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

Subject: [sca-j] ISSUE LOGGED: JAVA-4: Dependency reinjection

http://www.osoa.org/jira/browse/JAVA-4

________________________________

Von: Michael Rowley [mailto:mrow...@bea.com]

Gesendet: Mittwoch, 26. September 2007 00:31

An: sca...@lists.oasis-open.org

Betreff: [sca-j] NEW ISSUE: Dependency reinjection

TARGET: Java Common Annotations and APIs specification

section "@Reference"

DESCRIPTION:

The description of the @Reference annotation does not specify what

happens if the wire changes after the component has been instantiated.

One example of a place where this could occur is for a composite-scoped

component that exists at the domain level. The target of its reference

could start off unwired (and thus would be null). A later deployment

could deploy a <wire source="" target=""> element which provides a

target for this component.

PROPOSAL:

In the above scenario, when constructor-based injection is not being

used, the target MAY be reinjected.

This would be marked as "MAY" behavior, since it would not be required

of all runtimes. However, the developer who is creating portable code

needs to know that this reinjection may occur.

Other scenarios where such reinjection may occur is TBD. Note that

reinjection should never occur for a conversational-scoped component

that is in middle of its conversation.