[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Raw chat room text from March 13, 2008 meeting.
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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]