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: Minutes : 09-01-2009

Mark Combellack: - Roll Call
- Appointment of scribe. List attached below
- Agenda bashing
- Approval of minutes from January 5th

Issue Status:
Open: 60

1. Review action items:

Action Items that I believe are done:

Action Items that I believe are still to be done:
2008-07-15-2: Vladimir to produce a proposal for JAVA-2
2008-10-06-1: Editors to fix all the other remaining ed issues for WD04 pointed out by Mark, SimonN and Vamsi
2008-10-06-2: Anish - Work with OASIS Staff to get CD01 published - blocked by package name appeal
2008-10-20-1: Simon to write new proposal with textual changes for JAVA-76
2008-11-11-3: Simon to provide proposal for JAVA-6
2008-11-11-5: MikeE and Dave to write up a proposal to JAVA-1 covering the options decided at the Nov F2F
2008-11-11-7: Mark to propose a delta to Simon's action (2008-11-11-6) on JAVA-25 to add support for message correlation on call backs
2008-11-11-8: SimonN to write spec change proposal to resolve JAVA-19 as directed at the Nov F2F
2008-11-11-12: Mark to write proposal for JAVA-46 drawing inspiration from the chat log of day 2 of the November F2F
2008-11-11-13: Dave to work on proposal for JAVA-60
2008-11-11-21: Mark, Jim and Mike to describe their use cases for JAVA-30
2008-11-11-22: Mark to draw up some wording for Direction 1 (as discussed at the November F2F) for JAVA-62
2008-11-11-23: Mark (and others prepared to help) to investigate the WorkManager JEE spec and determine its applicability to SCA for JAVA-62
2008-11-11-27: SimonN to raise issue on brain-damaged definition of @Service annotation (see comments in Nov F2F raw chat log)
2008-11-11-33: Simon to write up proposal for JAVA-67 (not in previous minutes but Simon is sure he has this action item)
2009-01-05-01: Dave to ask Martin to pursue selection of domain name before January 31 through dialog with OASIS people
2009-01-05-02: Simon to find use cases for conversational interactions
2009-01-05-03: Simon to illustrate his proposal for Java-95 with use cases from action item 2009-01-05-02
2009-01-05-04: Jim to illustrate his proposal for Java-95 with use cases from action item 2009-01-05-02

2. Continuation of discussion on blocking issue from previous meeting

a. JAVA-95: Simplified stateful implementation mechanism to replace conversations
Proposal: http://lists.oasis-open.org/archives/sca-j/200812/msg00021.html
Comments from Jim: http://lists.oasis-open.org/archives/sca-j/200812/msg00098.html

3. Accepting New Issues

a. JAVA-117: Clarify the name implied by setter method for property and reference names
Comments from Jim: http://lists.oasis-open.org/archives/sca-j/200812/msg00070.html

4. Blocking Issue discussion

a. JAVA-25: Callback Simplification
Proposal: http://lists.oasis-open.org/archives/sca-j/200812/msg00015.html

5. Other Open Issues discussion

a. JAVA-96: Are annotations allowed on static methods
proposal: http://lists.oasis-open.org/archives/sca-j/200812/msg00046.html

b. JAVA-94: Missing normative guidance on the usage of annotations in unsupported ways
proposal: http://lists.oasis-open.org/archives/sca-j/200901/msg00010.html

c. JAVA-99: @property and @reference cannot be final
proposal: http://www.osoa.org/jira/browse/JAVA-99

d. JAVA-52: RequestContext.getCallbackReference() description inadequate
proposal: http://www.osoa.org/jira/browse/JAVA-52

e. JAVA-30: "Process" Scope
proposal: http://lists.oasis-open.org/archives/sca-j/200812/msg00006.html

f. JAVA-65: There is no lifecycle defined for SCA Components
proposal: http://lists.oasis-open.org/archives/sca-j/200811/msg00095.html

g. JAVA-101: element not fully described in Java CAA specification
proposal: http://www.osoa.org/jira/browse/JAVA-101

h. JAVA-102: Need to have a Name parameter on the @Service annotation
proposal: http://www.osoa.org/jira/browse/JAVA-102

i. JAVA-62: Clarify what a Component Implementation can do with threads
proposal: http://www.osoa.org/jira/browse/JAVA-62

6. AOB

Rotating scribe list:

Peter Walker Sun Microsystems (1)
Roberto Chinnici Sun Microsystems (2)
Peter Peshev SAP AG (2)
Ron Barack SAP AG (3)
Michael Beisiegel IBM (3)
Sanjay Patil SAP AG (3)
Vladimir Savchenko SAP AG (1)
Jim Marino Individual (4)
Meeraj Kunnumpurath Individual (1)
Vamsavardhana Chillakuru IBM (2)
Pradeep Simha TIBCO Software Inc. (5)
Mike Edwards IBM (5)
Anish Karmarkar Oracle Corporation (6)
Yang Lei (2)
Plamen Pavlov SAP AG (1)
Bryan Aupperle IBM (5)
Martin Chapman Oracle Corporation (5)
Ashok Malhotra Oracle Corporation (5)
Simon Nash Individual (3)
anonymous morphed into Yang Lei
Meeraj: no comments on the agenda
Meeraj: minutes from 5th Jan - no comments
Meeraj: no objections
Meeraj: Siomon completed use cases for conversations
anonymous1 morphed into Martin C
anonymous morphed into anish
Meeraj: Simplified stateful invocation model to replace conversations
Meeraj: Race issue with Jim's proposal of container generated id with multiple threads
Meeraj: with client side state maintenance
Mark Combellack lowered your hand
anish: don't cast it out yet, i'm interested in it too
Meeraj: Meeraj suggested leaving existing conversation semantics for optional compliance
Meeraj: Siomon raised a concsern about this adding confusion
Meeraj: Dave: I missed your point, sorry, could you pls type that in?
Meeraj: Optional compliance more from an assembly perspective
Mark Combellack lowered your hand
anish: meeraj, would the fact the SCA has extensibility help you here?
Meeraj: Martin suggested to defer the discussion within Java till assembly decides
Meeraj: Martin made a motion on the above
Meeraj: Meeraj seconded
Meeraj: Anish, would that mean conersations as they are in the spec disappear all together and become a vendor provided extension?
anish: yes, with a potential for incorporating some version of it, after more experience, in v.next
Meeraj: Simon suggested even if assemvbly retains conversations, doesn't necessarily mean Java continues the current model
Dave Booz: +1 to Martin
Mark Combellack lowered your hand
Meeraj: +1 to Martin : Meeraj
Meeraj: vote on Martin's motion
Meeraj: Siomon objects to the motion
Meeraj: Simon: apologies for mispelling your name
Meeraj: 10 yes(s) and 2 no(s)
Meeraj: mtion approved
Meeraj: discussion on the topic deferred
Meeraj: 117 name for setteres for props and refs
Meeraj: in the absence of name attribute inferred from the setter name
Meeraj: if the setter doesn't comply with Java bean naming convetions, should it be an error?
Meeraj: Vamsi makes a motion to accept the issue
Meeraj: Mike seconded
Meeraj: no objections
Meeraj: 117 opened
Meeraj: Dave suggested Vamsi to have a proposal
Meeraj: Vamsi to produce a proposal for 117 (action)
Meeraj: 25 callback simplification
Meeraj: Mark suggested this is related to 95
Meeraj: Mike agreed with Mark
Meeraj: Simon requested an informal discussion
Meeraj: Mark suggested to delay till Monday
Meeraj: Other open issues
Mark Combellack lowered your hand
anish: editorial comment: s/As a general rule//
Meeraj: not to allow annotations on static methids or fields
Meeraj: 96
Mike Edwards: I will now be on mute as the fire alarm test is taking place her
Meeraj: Vamsi makes a motion to accept 96
Meeraj: with Anish's change
Meeraj: Mike seconds
Meeraj: no objections to mark 96 resolved
Meeraj: 96 resolved
Vamsi: motion to "resolve" issue 96
anish: http://lists.oasis-open.org/archives/sca-j/200901/bin00003.bin
anish: am concerned about defining the same targets in each spec. would rather see them being defined in assembly and referenced in all other specs
anish: I prefer something along the lines of must not be deployed
Mark Combellack: Action Item: Bryan A: Raise a new issue for lack of Conformance section and include text from latest proposal for JAVA-96
Vamsi: timeout for the call.
Meeraj: Mike suggested that the container must refuse to *run* the component with invalid annotations
anish: eg:  An SCA runtime MUST verify the proper use of all annotations and if an annotation is improperly used, the SCA runtime MUST NOT deploy the component containing the improper annotation.
Mike Edwards: An SCA runtime MUST verify the proper use of all annotations and if an annotation is improperly used, the SCA runtime MUST NOT run the component which uses the invalid implementation code.
Mark Combellack lowered your hand
Meeraj: 9:4 chapter 8, proposed text, with Mike's sentence at the end?
Meeraj: 94
Meeraj: last sentence replaced by Mike's sentence
Meeraj: Motion from Brian, seconded by Mike
Meeraj: no discussion
Meeraj: no objections
Meeraj: 94 resolved

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