Minutes : 09-01-2009

Mark Combellack: - Roll Call
http://www.oasis-open.org/committees/membership.php?wg_abbrev=sca-j

- Appointment of scribe. List attached below
- Agenda bashing
- Approval of minutes from January 5th
http://www.oasis-open.org/committees/download.php/30579/SCA%20Java%20Minutes%202009-01-05.doc


Issue Status:
Open: 60


1. Review action items:

Action Items that I believe are done:
None

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

http://www.osoa.org/jira/browse/JAVA-95
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

http://www.osoa.org/jira/browse/JAVA-117
Comments from Jim: http://lists.oasis-open.org/archives/sca-j/200812/msg00070.html



4. Blocking Issue discussion

a. JAVA-25: Callback Simplification
http://www.osoa.org/jira/browse/JAVA-25
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
http://www.osoa.org/jira/browse/JAVA-96
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
http://www.osoa.org/jira/browse/JAVA-94
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
http://www.osoa.org/jira/browse/JAVA-30

proposal: http://lists.oasis-open.org/archives/sca-j/200812/msg00006.html

f. JAVA-65: There is no lifecycle defined for SCA Components

http://www.osoa.org/jira/browse/JAVA-65
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

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: 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: last sentence replaced by Mike's sentence

Meeraj: Motion from Brian, seconded by Mike

Meeraj: no discussion

Meeraj: no objections

Meeraj: 94 resolved

sca-j message