[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Raw minutes 7th Feb 08
> >Martin C: scribe: Martin C > >Martin C: Agenda: > >Martin C: >- 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 previous meeting(s) >http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php /27106/SCA%20Java%20Minutes%202008-01-31.doc > >1. Accepting new issues: > >NEW ISSUE: The EJB bindings specification should provide >explicity statesupport or non-support for Callbacks >RAISER: Dave Booz >http://lists.oasis-open.org/archives/sca-j/200802/msg00003.html > >2. Issues discussion > >JAVA-4: Dependency Reinjection http://www.osoa.org/jira/browse/JAVA-4 > >Latest version of the proposed issue resolution: >http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php /27104/Issue_4_Resolution_01.doc > >Latest version of the spreadsheet: >http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php /27105/Dynamic%20Modification%20Behavior%>20v6.xls > > >JAVA-11: Semantics of getCallbackID() are underspecified >http://www.osoa.org/jira/browse/JAVA-11 >- latest discussion is in the following email: >http://lists.oasis-open.org/archives/sca-j/200802/msg00002.html > >JAVA-12: Relation between conversational annotation and scope >conversation http://www.osoa.org/jira/browse/JAVA-12 >- latest discussion and proposal is in the following email: >http://www.oasis-open.org/apps/org/workgroup/sca-j/email/archiv es/200710/msg00038.html > >JAVA-8: Concurrency model for Service Reference instances >http://www.osoa.org/jira/browse/JAVA-8 >- proposal is in the following email and slide deck: >http://www.oasis-open.org/apps/org/workgroup/sca-j/email/archiv es/200710/msg00048.html >http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php /25725/sca-j-issue_8_proposal.ppt > >3. Adjourn > >anish martin, add that to the list of features you would like >OASIS to enable/add > >Martin C: Topic: agenda > >Mike Edwards: is the call running? > >Martin C: agenda approved > >Martin C: meeting in quorate > >Martin C: Topic: approval of minutes > >Simon Nash: s/in/is/ > >Mike Edwards: I dialled the # on the agenda and all I have is music! > >Martin C: >http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php /27106/SCA%20Java%20Minutes%202008-01-31.doc > >Simon Nash: so diD i > >Simon Nash: WE ARE ALL ON THE CALL TALKING > >Simon Nash: sorry for caps > >anish mikeE, the call is running > >Martin C: no objections, minutes approved > >Martin C: Topic: new issues > >Martin C: Dave Booz: The EJB bindings specification should >provide explicity statesupport or non-support for Callbacks >RAISER: Dave Booz >http://lists.oasis-open.org/archives/sca-j/200802/msg00003.html > >Mike Edwards: the international dial -in is not working > >Martin C: issue in bindings tc that bindings should address >conversations and callbacks and this includes the ejb binding >under this TC > >Martin C: Dave B: moves to open the ejb callback issue. 2nd >Simon. No objections, motion passed > >Martin C: topic: Issues discussion > >Martin C: >JAVA-4: Dependency Reinjection http://www.osoa.org/jira/browse/JAVA-4 > >Latest version of the proposed issue resolution: >http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php /27104/Issue_4_Resolution_01.doc > >Latest version of the spreadsheet: >http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php /27105/Dynamic%20Modification%20Behavior%>20v6.xls > >Martin C: simon thanks mike E for doing the work! > >Martin C: Motion by Simon: adopt the resolution of the two >previous links. > >Martin C: s/of/in > >Martin C: as a resolution of issue 4 > >Martin C: 2nd Mike E > >Martin C: Martin asks what it means to adopt the spreadsheet. > >anish prefer inline as well > >Martin C: Simon: expect it to appear inline with text and to >cross-reference > >Martin C: Anish: the table is normative > >Martin C: Mike R: notes the very last channge, reinjection of >values in a collection (multiplicity greater than one) has not >yet been discuseed by the group > >Martin C: Mike E: clarifies > >Martin C: Mike E: theres a potential for multi-threading issues > >Martin C: Mark C: is this a shallow treatment of the collection? > >Martin C: Mark C: is this a shallow treatment of the collection? > >Martin C: Mark C: is this a shallow treatment of the collection? > >Martin C: Mark C: is this a shallow treatment of the collection? > >Mike Edwards: yes > >Martin C: Mike: yes > >Mike Edwards: the contained objects are the reference proxies > >Mike Edwards: and I'd only expect one copy of each of those at a time > >Martin C: No objections to unanomous consent. Issue 4 is resolved > >Martin C: s/unanomous/unanimous/ > >Martin C: JAVA-11: Semantics of getCallbackID() are >underspecified http://www.osoa.org/jira/browse/JAVA-11 >- latest discussion is in the following email: >http://lists.oasis-open.org/archives/sca-j/200802/msg00002.html > >Martin C: Simon presents proposal, though notes there are no >extact spec words > >Mike Edwards: I have to admit a preference for specific spec >wording changes, due to debates about RFC 2119 wording > >Martin C: +1 > >Martin C: Proposal is to ensure a callbackid is never null > >Martin C: Mike R: its not clear, when/if the callback id can >change, and its not obvious is should be clear. > >Martin C: i.e. the callbackid may change over the lifecycle. >Is it a case to ignore? > >Mike Edwards: its essential that it changes > >Martin C: Simon: as a resolution to this issue, we should stay >silent, and is a separate issue > >Michael Rowley: The identity that is used to identify a >callback request is initially generated by the system. > >Mike Edwards: line # ? > >Michael Rowley: change ", by default," to "initially". > >Martin C: section 6.7.6 > >Martin C: Motion: Simon. Mik e 2nd. resolve issue 11, to >change ", by default," to "initially" in section 6.7.6 > >Martin C: new line should read: The identity that is used to >identify a callback request is initially generated by the system. > >Martin C: no objections. motion passed. > >Martin C: Mike R: requests editors to fold in the resolved issues > >Martin C: Mike E: Jira needs updating to point to where >decisions have been made > >Martin C: Mike R: JIRA is up to date apart from today's resolutions > >Martin C: Anish will do the editorial work > >Martin C: ACTION: Anish to update the spec with current rsolutions > >Peter Peshev: >http://www.oasis-open.org/apps/org/workgroup/sca-j/email/archiv es/200802/msg00008.html > >Martin C: JAVA-12: Relation between conversational annotation >and scope conversation http://www.osoa.org/jira/browse/JAVA-12 >- latest discussion and proposal is in the following email: >http://www.oasis-open.org/apps/org/workgroup/sca-j/email/archiv es/200710/msg00038.html > >Martin C: Peter posted latest emeil on issue above > >Martin C: s/emeil/email/ > >Martin C: review of proposal in >http://www.oasis-open.org/apps/org/workgroup/sca-j/email/archiv es/200802/msg00008.html > >Peter Peshev: >http://www.oasis-open.org/apps/org/workgroup/sca-j/email/archiv es/200802/msg00008.html > >Martin C: just looking at peter's new text at the begining not >any text in the thread > >Martin C: Mike E: not clear what normative statements are applied to > >Martin C: Simon, needs some rewording, and be clear what the target is > >Martin C: Mike E: another problem. what if impl code >implements more than one interface. One could be >conversational one couldnt > >Simon Nash: The SCA runtime MUST generate an error when a >CONVERSATIONAL class exposing a service over a >non-conversational interface is deployed. > >Martin C: is this case covered > >Martin C: Mike E: that means it is not possible to mix in one >impl a conversational and a non-conversational service > >Simon Nash: The SCA runtime MUST generate an error when a >conversationally scoped implementation exposing a service over >a non-conversational interface is deployed. > >Michael Rowley: A conversational scoped class MUST NOT expose >a service using a non-conversational interface. > >Mike Edwards: +1 > >Martin C: Anish: dont we need both statements > >Martin C: Mike R: yes but hoping can centralize in the >document the runtime rules > >Martin C: Motion: Peter: add these words to the spec "A >conversational scoped class MUST NOT expose a service using a >non-conversational interface." > >Martin C: to go in 2.4.4 > >Mike Edwards: +1 to 2.4.4 > >Martin C: 2nd: Simon > >Martin C: Dave: an unannotated pojo might cause trouble > >Martin C: MIke E: not an issue as will be stateless > >Martin C: No objecstions. Motion passes > >Michael Rowley: The instances of the class StatelessClass are >NOT REQUIRED to contain conversational state between methods; >Any instance can be used for any client. An SCA runtime MAY >provide a pool of such objects and reuse them among calling >clients or MAY instantiate each time a new instance. >ConversationalId MUST be provided since the interface was >marked via @Conversational > >Martin C: Simon: other combinations might be possible and >above s not clear > >Martin C: s/s/is/ > >Martin C: that current case doesn't include all cases that >need to be considered > >Michael Rowley: If a class is not conversion scoped, then >offering a service that uses a conversational scope does not >affect the state that must be maintained for instances of that class. > >Martin C: s/conversational scope/conversational interface/ > >Simon Nash: s/conversion/conversation > >Michael Rowley: However, getConversationID() should return >non-null when operations of the conversational interface are invoked. > >Martin C: Mike R: making explicit what is already implicit > >Martin C: silence...... > >Simon Nash: not so keen on the second part > >Martin C we are out of time > >Martin C: Mike E: needs to think more > >Martin C: Simon: iterate over email > >Martin C: ACTION: Mike R to send issue 12 proposal > >Martin C: AOB: > >Martin C: roll call update > >Martin C: meeting adjouned >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]