[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-j] ISSUE 4 - Dependency reinjection
|
Peter, Thanks for the comments. Responses inline... -----Original Message----- 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: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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]