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

["Peshev, Peter" <peter.peshev@sap.com>]

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)


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.


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 ? 

 
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.


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 ?


Best Regards
Peter
 

________________________________

From: Michael Rowley [mailto:mrowley@bea.com] 
Sent: Thursday, 29. November 2007 22:19
To: sca-j@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.barack@sap.com] 
Sent: Thursday, October 04, 2007 5:27 AM
To: sca-j@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:mrowley@bea.com] 
Gesendet: Mittwoch, 26. September 2007 00:31
An: sca-j@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.