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

[Simon Nash <NASH@uk.ibm.com>]

Now that we have agreed to permit reinjection into conversational-scoped 
instances, this (re)raises the question of callback reinjection.

We had decided not to permit this at all, based on the earlier decisions 
to limit reinjection to composite-scoped instances only, and to prohibit 
callback injection into composite-scoped instances.

The reversal of the first of these decisions means that we need to 
consider the case of a conversational-scoped instance with a bidirectional 
interface that is invoked by two different callers using the same 
application-generated conversationID.  Section 6.6.1 gives some hints that 
it is possible, without saying so explicitly.

We could address this in (at least) four ways:
1. Prohibit callback injection for conversation-scoped components, as we 
have done for composite-scoped components.  This seems bad because it 
penalises a common case (calls from one client per conversational 
instance) in favour of a rare case (calls from multiple clients per 
conversational instance).
2. Say that in this case, callback reinjection MUST be done.  This goes 
against the "big MAY" for other types of reinjection.  It can also lead to 
non-deterministic behavior in multithreaded scenarios.
3. Say that in this case, callback reinjection MUST NOT be done.  This 
puts the burden on developers to know that they should avoid using 
injected callbacks if there is a possibilty that the component will be 
invoked by multiple clients within the same conversation.
4. Say that in this case, callback reinjection MAY be done.  This has a 
similar effect to option 3. 

To start the ball rolling, I suggest that we adopt option 3.  What do 
others think?

    Simon

Simon C. Nash, IBM Distinguished Engineer
Member of the IBM Academy of Technology
Tel. +44-1962-815156  Fax +44-1962-818999



Simon Nash/UK/IBM@IBMGB 
15/01/2008 22:32

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

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






Two approved motions from last week's call were not incorporated into the 
v3 version of the table.  These were:

1. ComponentContext.getServiceReference() should be always in sync with 
the current configuration of the domain

2. no objections to dropping the column, as long as long as the text typed 

by Michael is present

I have made these changes in the v4 version (attached).



    Simon

Simon C. Nash, IBM Distinguished Engineer
Member of the IBM Academy of Technology
Tel. +44-1962-815156  Fax +44-1962-818999



"Michael Rowley" <mrowley@bea.com> 
10/01/2008 21:19

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

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






 
Here is an updated table, based on the last TC meeting.
 
Michael
 ---------------------------------------------------------------------
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





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

Dynamic Modification Behavior v3.xls

Dynamic Modification Behavior v4.xls