Java Call minutes, 1 Nov 2007

[Jim Marino <jmarino@bea.com>]

Below are the minutes for the 1 November SCA Java call

Jim



Room information was updated by: Sanjay
US & Canada Toll Free: (866) 484-4232
International Dial-In Number: (702) 894-2358
ACCESS CODE:  960335
Mike Edwards: hi
anonymous morphed into henning
Michael Rowley: Is anyone here who isn't on the call?
Martin C1 morphed into Martin C
Martin C: anyone on the call and not in the chat room
Martin C:

Simon Nash: here now
Sanjay: Scribe: Jim Marino
Jim Marino1: Heening: Agenda was sent out. First point: inter-SCA liason
henning: http://www.oasis-open.org/apps/org/workgroup/sca-j/email/ 
archives/200710/msg00064.html
Jim Marino1: Mike E: Recommendation was approved by the Assembly  
Group. Moved that the co-chairs would be the reps for the Assembly TC
Jim Marino1: Martin: Move that two chairs be the liasons
Michael Rowley: Attendance:  Voting Members: 17 of 20 (85%) (used for  
quorum calculation)
Mike Edwards: loud & clear, Jim
Jim Marino: Dave and Sanjar second
Jim Marino: Henning: Any issues?
Jim Marino1: [Nothing raised]
Jim Marino2: Henning: We have our members, Henning and Mike
Jim Marino: Henning: need to approve minutes from last week
Jim Marino: Simon N: motiuon to approve minutes
Jim Marino1: Mike R: second
Jim Marino2: [no discussion, objections. Minutes accepted
Jim Marino: Henning: agenda item 3
henning: http://www.osoa.org/jira/browse/JAVA-16
Jim Marino: Mike E: 15 is general. 16 is a specific one
anish waves
anish the distinction is lost on me
Jim Marino: Henning: Would we loose info if we combined the issues  
into one?
Dave Booz me too
Simon Nash: there is a Q
Jim Marino: Simon: two comments. "Fully configured" is not consistent  
in both issues.
Jim Marino: Simon: Fully in 15 is fully ready to go, Fully in 16 is  
fully described
anish: to me 'fully' means that anything one can do in CT we should  
be able to do thru annotation
Jim Marino: Simon: Second comment is not sure about principle 16  
would estb, i.e. would it require everytime to have an annotation?
Jim Marino: Mike E: 16 implies that a Java annot should correspond to  
every new metadata item added
Jim Marino: Mike E: 16 implies that a Java annot should correspond to  
every new metadata item added
anish: ... i would add that teh converse is not tru
anish: i.e. anything that one can do thru annotations, may not be  
possible thru CT
anish: by CT i mean CT side file
Jim Marino: Ron: Feels that they should be one issue
Jim Marino: Mike R: moves that we close 16 as duplicate
Jim Marino: Anish: seconds the proposal
Jim Marino: Henning: any more discussion, objections [none]
Jim Marino: Motion carries
Jim Marino: Motion carries
anish: close 16 as a duplicate of 15
henning: http://www.osoa.org/jira/browse/JAVA-17
Jim Marino: Henning: Brings us to Issue 17
anish: i think this is a good issue to accept
Dave Booz: +1 to anish
Jim Marino: Anish: move toaccept issue
Jim Marino: Simon: second
Jim Marino: No objections
Jim Marino: Topic: Errata
Jim Marino: Mike R: moves that we direct editors to apply the errata  
to relevent specs
Jim Marino: Dave: Seconds
Jim Marino: [no objections]
anish: note that this is really errata
anish: i.e. minor stuff
Jim Marino: mechanics will be worked on the editors' list
Jim Marino: Simon's reinjection proposal
henning: On last week's SCA-J call, I took an action to consider what  
the callback
target would be if multiple forward calls are made to callback  
interfaces
of a composite-scoped component.

I can think of 3 options:

1. Use the value from the last forward call that was made.  This could
lead to a need for reinjection.  It is not safe if the component can
receive multithreaded forward invocations.
2. Store the callback address on the thread when a forward call is
received, and use this address for the callback.  This works with
multithreaded forward invocations but does not work if a forward request
spins off a new thread to make the callback.
3. When the callback request is made, take the callback address from the
current RequestContext.  This is a small variation on 2, but it is more
robust because it uses official APIs.

I think 3 is the best approach.

     Simon
henning: Q fills up...
anish: 1 doesn't sound like a good choice
henning: but you need to serialize calls.
Michael Rowley: Random routing of callbacks, sounds good to me

anish:

Jim Marino: Composite scoped impls can be multi-threaded
anish: like 3 over 2
henning: +1 for 3
henning: +1 for 3
Jim Marino: Mike R: suggests @Callback should be disallowed for  
composite scope
Jim Marino: Mike R: suggests @Callback should be disallowed for  
composite scope
Jim Marino: Jim and Simon bring up injection proxy
anish: ... and what you use would depend on the scope (composite, etc)?
anish: ... and what you use would depend on the scope (composite, etc)?
Dave Booz: let's not forget about conversational callbacks
Dave Booz: let's not forget about conversational callbacks
Dave Booz: time check please
Jim Marino: Long discussion on option 2
henning: point is: it is ok to keep a ref and invoke it from another  
thread (think: service call). It should still point to the same target
henning: 4 ins over!
henning: 4 ins over!
henning: s/ins/mins
Jim Marino: will continue discussions on ML
Jim Marino: additional attendees: none
Jim Marino: additional attendees: none
Jim Marino: end of meeting