OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sca-j message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: SCA-J minutes 6 Dec 2007

Michael Rowley: US & Canada Toll Free: (866) 484-4232
International Dial-In Number: (702) 894-2358

Chat room: http://webconf.soaphub.org/conf/room/sca-j-TC
Agenda 1. Preliminaries

- Roll Call

- Appointment of scribe. List attached below
- Agenda bashing
- Approval of minutes from previous meeting(s)

2. Accepting new issues:

None submitted.

3 . Issues discussion

Issue #4: Dependency Reinjection
Continuing from the 2007-11-08 meeting and the 2007-11-29 meeting,  
where we decided:
- The editors should be directed to add wording to the specification:  
Dependency injection for callbacks cannot be used for composite scoped  
- The setcallback method can not be called while a conversation is in  
progress. The spec should say that @Callbacks will never be reinjected.

This week: reference reinjection as described in the issue:

Please review mail thread startin from Michael Rowley's proposal:http://www.oasis-open.org/apps/org/workgroup/sca-j/email/archives/200711/msg00029.html

Issue #3 - Local services expose implementation classes as their type
see mail thread: http://lists.oasis-open.org/archives/sca-j/200710/msg00059.html

Issue #8: Concurrency model for Service Reference instances

4. Adjourn

Rotating scribe list:

Martin Chapman Oracle Corporation
Jason Kinner Oracle Corporation
Jeff Mischkinsky Oracle Corporation
Peter Peshev SAP AG
Roberto Chinnici Sun Microsystems
Peter Walker Sun Microsystems
Sriram Narasimhan TIBCO Software Inc.
Pradeep Simha TIBCO Software Inc.
Scott Vorthmann TIBCO Software Inc.
Bryan Aupperle IBM
Michael Keith Oracle Corporation
Uday Joshi Oracle Corporation
---- scribed once -----
Anish Karmarkar Oracle Corporation
Mike Edwards IBM
Michael Beisiegel IBM
Ashok Malhotra Oracle Corporation
David Booz IBM
Simon Nash IBM
Jim Marino BEA Systems, Inc.
Ron Barack SAP AG
Sanjay Patil SAP AG

anish michael i just joined

anish pl. put me on the roll, when u get a chance

Dave Booz and we need a scribe

Jason Kinner: Scribe: Jason Kinner

henning: Ron is here now!

Jason Kinner: M: Walker, S: Beisiegel to accept minutes from last  
meeting accepted w/o

Jason Kinner: Nash: Combined meeting with Bindings during w/c 3 March;  
preference for Tue-Fri; bindings prefers Tue-Wed

Jason Kinner: Karmarkar: Suggests we alternate first picks

Jason Kinner: Nash to deliver recommendation for Tue-Wed for Bindings,  
Thu-Fri for Java at F2F

Mike Edwards: I joined too !

Jason Kinner: Roll: 9/17 53% quorate

Jason Kinner: Discussion about Issue #4

Jason Kinner: Booz: We eliminated constructor reinjection because it  
isn't possible in Java. Depending on a current behavior of Java.  
Relying on this as the sole mechanism to indicate lack of support for  
reinjection may not hold if Java changes. Would prefer an explicit  

Jason Kinner: Rowley: Should be possible to rewire target of some of  
the references without requiring restart of, say, a process

Jason Kinner: Edwards: Seems reasonable to use constructor injection  
to disallow reinjection, since Java doesn't support reinjection in  
this way

henning: Jim: this does not count as majortiy!!

Jason Kinner: [henning] ???

henning: (just kidding about raising your hand 3 times under different  

Jason Kinner: Rowley: Applicable to "conversational" scope components?

Jason Kinner: Conversational component wired to non-conversational  
interface, in what way is it an issue to be rewired?

Jason Kinner: Blohm: Non-conversational component may still be  
"stateful" in that it could have information in DB, etc., and  
conversational component may rely on that state

Jason Kinner: Peshev: Consider a case where a conversational component  
invokes the non-conversational component multiple times over a longer  
period of time. The wiring changes between these invocation.

Jason Kinner: Marino: Isn't it the job of the runtime to migrate state  
if necessary?

Jason Kinner: Marino: Or, if the state cannot be migrated, wouldn't it  
be an error to rewire it?

Jason Kinner: M: Blohm, S: Nash reinjection should NOT be applicable  
to conversation components

Jason Kinner: s/conversation/conversational/

Mike Edwards: If I dont allow reinjection then how did the component  
get the update

Mike Edwards: in which case the component involved lives with the old  

Jason Kinner: Blohm: Perhaps this should be the behavior if  
reinjection is not supported? You can always get the latest by querying.

Jason Kinner: Booz: Issue is with the reference, not the target  

Jason Kinner: Peshev: References should at least be invalidated on a  

Jason Kinner: Nash: If the conversational component holding the  
reference to the previous target, then any subsequent attempt should  
throw an error

Jason Kinner: Blohm: If the target changes, then references to the  
target should be invalid

Jason Kinner: Nash: A->B, then A->C, but instance of A still refers to  
B; could I still get B? An error?

anish requests a private chat with you

Mike Edwards: this raises all the meta-issues about the behaviour of  
the domain

Jason Kinner: Rowley: For "stateless" or "request", the instance  
doesn't live long enough to matter; "composite" lives longer, so it  
matters, "conversational" matters.

Jason Kinner: Nash: Transparently redirecting to C might matter

Jason Kinner: Blohm: If the rewiring directs you to new state, it  
could matter

henning: very good example!!

Mike Edwards: I was trying to point out that this discussion impinges  
on how the evolution of the domain is described

Mike Edwards: if the  component can carry on using the "old wiring",  
then in effect you have multiple versions of the domain config in  
existence at the same time

Jason Kinner: Rowley: What if the composite relies on BPEL (business  
data in the message) for correlation. From SCA, the component is  
stateless, but it isn't, truly.

Jason Kinner: [Mike: I agree, and I was trying to point out earlier  
that it could be desirable to have that behavior]

Jason Kinner: Booz: What if the new component is actually  
interchangeable with the previous target?

Jason Kinner: Rowley: Interface isn't enough to determine if the  
components are interchangeable

Mike Edwards: it would be wise to examine that design further before  
we try to make a decision on this less important point

anish michaelR, I have to go can u get me on the role please

anish unfortunately, can't stay for straggler roll

anish s/role/roll/

Michael Rowley will do

Jason Kinner: Kinner: Are we really just describing an optimization  
that isn't strictly required?

Jason Kinner: Rowley: Call for vote on the motion

Jason Kinner: M: Blohm, S: Nash reinjection should NOT be applicable  
to conversation components

Jason Kinner: s/conversation/conversational/

Jason Kinner: Motion passed: 8 for, 2 against, 5 abstain

Michael Rowley: Current proposal

Michael Rowley: 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  
- 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  

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.

Jason Kinner: Rowley: AI for all: Check the complete proposal and  
identify issues to be addressed for acceptance

Jason Kinner: Rowley: Will be meeting next week

Jason Kinner: Meeting adjourned

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]