anish now you sound like you are on a speakerphone 
</B< pre>
Michael Rowley: Agenda:
- Roll Call
http://www.oasis-open.org/committees/membership.php?wg_abbrev=sca-j
- Appointment of scribe. List attached below
- Agenda bashing
1. Review minutes (resolutions and actions) from F2F http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/27546/SCA%20Java%20Minutes%20F2F%20of%202008-03-06%20and%202008-03-07.doc
2. Get deadlines for actions listed in F2F minutes
3. Issues discussion
JAVA 25: Callback Simplification
- Decide on next action items.
JAVA-8: Concurrency model for Service Reference instances
http://www.osoa.org/jira/browse/JAVA-8
- latest discussion is here:
http://www.oasis-open.org/apps/org/workgroup/sca-j/email/archives/200802/msg00073.html
- original proposal is in the following email and slide deck:
http://www.oasis-open.org/apps/org/workgroup/sca-j/email/archives/200710/msg00048.html
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/25725/sca-j-issue_8_proposal.ppt
4. Adjourn
---------------------------------------------------------------
Rotating scribe list:
Ron Barack SAP AG
Peter Walker Sun Microsystems
Peter Peshev SAP AG
Roberto Chinnici Sun Microsystems
Pradeep Simha TIBCO Software Inc.
Anish Karmarkar Oracle Corporation
Martin Chapman Oracle Corporation
Michael Beisiegel IBM
David Booz IBM
Mike Edwards IBM
Ashok Malhotra Oracle Corporation
Jim Marino BEA Systems, Inc.
Sanjay Patil SAP AG
Pradeep: Scribe Pradeep
Pradeep: 8 out of 11 present. Meeting is quorate
Pradeep: Onto Agenda bashing
Pradeep: We will JAVA-8 first for about 20 minutes
Pradeep: Onto Reviewing minutes from F2F
Pradeep: Peter to take first cut at action for issue 1 with Jim - approx 2 weeks
Pradeep: s/action /action b
Pradeep: Mike: 2 weeks for action c for issue 1
Pradeep: Mike R: sent email for issue 21 laying out the idea. What are the next steps?
Pradeep: Mike R: Should it be sent to Policy TC and Assembly TC for consideration?
Pradeep: Mike R: We need to address the proposal further before handing over to assembly TC
Pradeep: Simon: Issue 12 should be resolved not closed
Pradeep: Simon: Issue 23 - 2 weeks from today for action item to come up with proposal
Pradeep: Meeting minutes approved without objections
Simon Nash: I presume the reference is to a conceptual internal "set" that would occur as part of rewiring, and not any "set" API call. With this understanding, your model for "get" semantics makes sense.
In our last discussion of the issue there seemed to be some support for introducing a createServiceReference() method on ComponentContext to return a newly created ServiceReference object. This solves the problem and is upward compatible with the existing API. We would probably also need to add a createServiceReferences() method with similar semantics.
The question then arises whether the semantics of getServiceReference() or getServiceReferences() need to be specified more tightly, for example to always return the same instance that was returned by a previous call except in some specified list of cases. I believe this isn't necessary or desirable, as it would over-constrain implementation flexibility.
So my proposal is to resolve this issue by adding the following methods to ComponentContext():
<B> ServiceReference<B> createServiceReference(Class<B> businessInterface, String referenceName) - Returns a newly created typed service reference for a business interface type and a reference name. This method MUST throw an IllegalArgumentException if the reference has multiplicity greater than one.
<B> Collection<ServiceReference<B>> createServiceReferences(Class<B> businessInterface, String referenceName) - Returns a list of newly created typed service references for a business interface type and a reference name.
Pradeep: Onto issue JAVA-8
Mike Edwards: The question to ask is whether it is valid for a client to conduct multiple simultaneous conversations with a given conversational service
Pradeep: Jim: We should probably remove getServicereference()
Pradeep: s/getServiceReference()/ServiceReference
anish: i think it is important to allow concurrent conversations with a given conversational service
Pradeep: Mike R:Callback Simplification talks about ServiceReference. Therefore, we should make issue JAVA-8 depend on JAVA-25
Pradeep: Mike E: Let us not link them. We should consider isuuse JAVA-8 as is.
Pradeep: Mike E: If a ServiceReference needs to shared between threads, it can be done so using locks.
Pradeep: Simon N: getServiceReference() can be left to in the implementation.
anish: why won't the code do a create and cache it, especially if it is single threaded
Pradeep: Simon N: If you don't care, then you can use getServiceReference().
Pradeep: Mike R: getServiceReference() may creata a new ServiceReference()
Pradeep: Mike R: May be getServiceReference() always returns the first one that was created.
anish: is the reason to keep get is for backward compat? if so, would this be deprecated?
Pradeep: Peter Peshev: We should be able to do multiple conversations without changing API
Pradeep: Simon N: We should put this on hold till we get to issue JAVA-25
anish got disconnected on the phone 
</B< pre>
anish was there a decision on 8?</B< pre>
Pradeep: Simon N: will write a proposal to JAVA-25
Pradeep: Simon N: focus next week on JAVA-25 and propagaing conversation
Pradeep: Meeting adjourned