Next in thread → Next in month →

RE: [sca-j] ISSUE 4 - Proposed spec text for dependency reinjection

From
Michael Rowley <>
Date
2008-02-11T15:40:05+00:00
ID
Thread
RE: [sca-j] ISSUE 4 - Proposed spec text for dependency reinjection
The resolution recorded in the JIRA does
include the comment that “The spec should say that @Callbacks will never
be reinjected.”  As Simon notes, however, the “will not” has
to be changed to “MUST NOT”, since the callback _can_ change.  I also like Simon’s
wording.

 

Michael

 

From: Simon
Nash [mailto:] 

Sent: Saturday, February 09, 2008
12:09 PM

To: OASIS Java

Subject: RE: [sca-j] ISSUE 4 -
Proposed spec text for dependency reinjection

 

Unfortunately something was omitted from the resolution
of this issue.  In our call of 1/31/08, we discussed the email thread in

 
  http://www.oasis-open.org/apps/org/workgroup/sca-j/email/archives/200801/msg00055.html

We
talked abut the various options and agreed (I thought) to adopt option 3.  Unfortunately
this decision was not recorded in the minutes and therefore did not appear in
the formal final resolution of this issue.  Here's the relevant section of
the minutes for that discussion: 

.....

anish:
topic: issue 4 

anish:
simon: 2 things to talk about one is on the agenda and the other isn't

anish:
... we have to consider injection and reinjection for conversations

anish:
simon: does anyone think that the scenario in my email can happen

anish:
mikeR: i do 

Dave
Booz: 

http://www.oasis-open.org/apps/org/workgroup/sca-j/email/archives/200801/msg00081.html

.....

To
correct this omission, I propose that the following text be added to the end of
the text in 

 
  http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/27104/Issue_4_Resolution_01.doc

that was adopted as the resolution of issue 4: 

Callback
references MUST NOT be reinjected.  If a conversational-scoped service
implementation is invoked by multiple clients using the same
application-generated conversationID, any injected callback reference will
refer to the client that made the initial invocation.  A reference to the
client that made the current invocation can be obtained by using the
RequestContext API. 

 
  Simon 

Simon C. Nash, IBM Distinguished Engineer

Member of the IBM
 Academy of Technology

Tel. +44-1962-815156  Fax +44-1962-818999 

 

  
  
"Michael
   Rowley" <> 

  
07/02/2008 19:05 

  
  
  
   

    
    
To

    
    
    
"OASIS Java"
    <> 

    
   

   

    
    
cc

    
    
    
 

    
   

   

    
    
Subject

    
    
    
RE: [sca-j] ISSUE 4 - Proposed spec text  for
    dependency reinjection

    
   

  
  
 

  
   

    
    
 

    
    
    
 

    
   

  
  

  
 

  

For the record, this issue was resolved on today’s
call.  Anish will be updating the spec based on this proposal
wording and this spreadsheet
table. 

  

Michael 

  

 

From: Mike Edwards
[mailto:] 

Sent: Friday, February 01, 2008 5:45 AM

To: OASIS Java

Subject: Re: [sca-j] ISSUE 4 - Proposed spec text for dependency
reinjection 

  

Folks, 

I've taken Simon's text and cast it into a Word document so that edits and
comments can be more 

easily tracked.  I've then made a few edits and comments, which I hope
improve the text and deal 

with one significant problem relating to the handling or reinjected
arrays/collections: 

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:   

 

  
  
Simon Nash/UK/IBM@IBMGB 

  
31/01/2008 15:24 

  
  
  
 

  
   

    
    
To

    
    
    
"OASIS Java" <>
    

    
   

   

    
    
cc

    
    
    
  

    
   

   

    
    
Subject

    
    
    
[sca-j] ISSUE 4 - Proposed spec text  for
    dependency reinjection

    
   

  
  

    

  
 

  
   

    
    
  

    
    
    
 

    
   

  
  

  
 

Here's my attempt to merge the contents of the v5 spreadsheet with 

Michael's original text.  There's bit more work still to do to capture the

decisions we made regarding callback injection and reinjection.

- - - - begin spec words - - - -

References MAY be reinjected after the initial creation of a component if 

the reference target changes 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:

1) The component MUST NOT be STATELESS or REQUEST scoped.

2) The reference MUST use either field-based injection or setter 

injection. References that are injected through constructor injection MUST 

NOT be changed.  Setter injection allows for code in the setter method to 

perform processing in reaction to a change.

3) If the reference has a conversational interface, then reinjection MUST 

NOT occur while the conversation is active.

If a reference target changes and the reference is not reinjected, it MUST 

continue to work as if the reference target was not changed.

If an operation is called on a reference where the target of that 

reference has been undeployed or has become unavailable, the SCA runtime 

SHOULD throw InvalidServiceException.  It the target of the reference is 

changed, the reference 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.

A ServiceReference that has been obtained from a reference by 

ComponentContext.cast() corresponds to the reference that is passed as a 

parameter to cast().  If the reference is subsequently reinjected, the 

ServiceReference MUST continue to work as if the reference target was not 

changed.  If the target of a ServiceReference has been undeployed or has 

become unavailable, the SCA runtime SHOULD throw InvalidServiceException. 

If the target of a ServiceReference is changed, the reference 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.

A reference or ServiceReference accessed through the component context by 

calling getService() or getServiceReference() MUST correspond to the 

current configuration of the domain.  If the target has been undeployed or

has become unavailable, the result SHOULD be a reference to the undeployed 

or unavailable service, and attempts to call business methods SHOULD throw 

InvalidServiceException.  If the target has changed, the result SHOULD be 

a reference to the changed service.

The rules for reference reinjection also apply to references with a 

multiplicity of 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.

- - - - end spec words - - - -

  Simon

Simon C. Nash, IBM Distinguished Engineer

Member of the IBM
 Academy of Technology

Tel. +44-1962-815156  Fax +44-1962-818999

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

 

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
Next in thread → Next in month →