SCA-J raw minutes - May 18th 2009

[Graham Charters <CHARTERS@uk.ibm.com>]

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 for 15th May 2009
http://www.oasis-open.org/committees/download.php/32561/SCA%20Java%20Minutes%202009-05-15.doc


0. Administration 
- Issue Status: Open: 31


1. Review action items:

Action Items that I believe are done:

Action Items that I believe are still to be done:
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
2009-05-11-01: Editors: remove extra space on line 767 of CD01 (PDF)
2009-05-11-02: Simon: Write a full proposal for JAVA-125 with all the required
metadata


2. Progress of the SCA-J specification to Public Review

a. Submitted for Public Review
http://lists.oasis-open.org/archives/sca-j/200905/msg00078.html


3. New Issues

None


4. Open Issues

a. JAVA-53: what happens if init() throws a runtime exception
http://www.osoa.org/jira/browse/JAVA-53
Already solved by JAVA-65?

b. JAVA-161: @Service attributes "value" and "interfaces"
should be combined
http://www.osoa.org/jira/browse/JAVA-161
Proposal in Jira

c. JAVA-1: Accessing SCA Services from non-SCA component code
http://www.osoa.org/jira/browse/JAVA-1
Latest discussions: http://lists.oasis-open.org/archives/sca-j/200904/msg00081.html
Updated Proposal: http://lists.oasis-open.org/archives/sca-j/200903/msg00227.html
Updated Proposal (PDF): http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/31871/sca-javacaa-1.1-spec-cd02-rev3%20Issue1%20rev%204.pdf

d. JAVA-155: Inconsistent normative statements in Chapter 10
http://www.osoa.org/jira/browse/JAVA-155
Discuss - What do we do next?

e. JAVA-125: Allow call semantics to be specified in interface.java
http://www.osoa.org/jira/browse/JAVA-125
Discuss - What do we do next?

f. JAVA-153: Java CI should have corresponding changes in JAVA-125
http://www.osoa.org/jira/browse/JAVA-153
Latest Proposal: http://lists.oasis-open.org/archives/sca-j/200905/msg00019.html

g. JAVA-139: Default value for SCA property is not supported for java implementations
http://www.osoa.org/jira/browse/JAVA-139
Outline of proposal in Jira

h. JAVA-127: Long running request/response operations
http://www.osoa.org/jira/browse/JAVA-127
Proposal: http://lists.oasis-open.org/archives/sca-j/200812/msg00089.html

i. JAVA-143: Guidelines for dealing with cyclic references refers to an
impossible situation
http://www.osoa.org/jira/browse/JAVA-143
Proposal in Jira

j. JAVA-131: @Callback injection could be NULL (expanded to include refs,
property and re-injection and callback
http://www.osoa.org/jira/browse/JAVA-131
Proposed direction for resolution: http://lists.oasis-open.org/archives/sca-j/200904/msg00002.html


5. Issues waiting for updated proposals

a. JAVA-46: equals() method on ServiceReference and CallableReference
http://www.osoa.org/jira/browse/JAVA-46
Waiting for updated proposal


6. Issues without proposals

a. JAVA-13: ComponentContext.getProperty(...) ill defined
http://www.osoa.org/jira/browse/JAVA-13
No proposal

b. JAVA-51: More examples on <interface.wsdl> mapping to Java
http://www.osoa.org/jira/browse/JAVA-51
No proposal

c. JAVA-54: Section 7.1 of the Java CAA Specification is unclear
http://www.osoa.org/jira/browse/JAVA-154
No proposal

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

e. JAVA-78: Need API to set EPR and for a reference invocation
http://www.osoa.org/jira/browse/JAVA-78
No proposal

f. JAVA-156: Intent annotations are missing from Java CAA as compared to
Policy FW spec
http://www.osoa.org/jira/browse/JAVA-156
No proposal


7. AOB

a. Straggler roll call


---------------------------------------------------------------
Rotating scribe list:

Ron Barack SAP AG (3)
Michael Beisiegel IBM (3)
Sanjay Patil SAP AG (3)
Jim Marino Individual (4)
Pradeep Simha TIBCO Software Inc. (5)
Vamsavardhana Chillakuru IBM (3)
Plamen Pavlov SAP AG (2)
Meeraj Kunnumpurath Individual (3)
Graham Charters IBM (2)
Anish Karmarkar Oracle Corporation (11)
Martin Chapman Oracle Corporation (9)
Ashok Malhotra Oracle Corporation (10)
Bryan Aupperle IBM (11)
Yang Lei (7)
Simon Nash Individual (8 )
Mike Edwards IBM (10)
Bryan Aupperle: As an agenda addition, we should
discuss if we will have a call one week from today.  It is a US holiday.
Graham Charters: It's also a UK holiday

Mark Combellack: I think cancelling is a good
ideas as holiday in UK
Mark Combellack: (or I could have typed +1
to what graham said

Bryan Aupperle: So it will be a *very* short
discussion

Mark Combellack: yep
Mike Edwards: I am listening to music
Mike Edwards: are youguys on the call?
Mark Combellack: me too
Graham Charters: Scribe: Graham Charters
Graham Charters: Agenda Bashing:
Graham Charters: One new item - considering
canceling May 25th call due to public holidays.
Graham Charters: Approval of minutes:
Graham Charters: No objections, approved as
posted.
Graham Charters: Action Items Review:
Graham Charters: All action items still outstanding.
Graham Charters: New Item: consider cancellation
of May 15th call due to US and UK holidays.
Graham Charters: Bryan Aupperle moved to cancel
call on 25th
Graham Charters: Seconded by Mike Edwards.
Graham Charters: No discussion.  Passed
unanimous consent.
Graham Charters: Progress of SCA-J spec to
public review:
Graham Charters: No update available.  Waiting
in limbo.
Graham Charters: New Issues:
Graham Charters: None
Graham Charters: Open Issues:
Graham Charters: JAVA-53: what happens if init()
throws a runtime exception
Graham Charters: Already solved by JAVA-65?
Dave Booz: If an exception is thrown whilst
initializing, the SCA Runtime MUST transition the component implementation
to the Destroying state. [JCA40015]
Graham Charters: Mike Edwards moves to close
JAVA-53 as resolved by JAVA-65
Graham Charters: Seconded by Bryan Aupperle
Graham Charters: Motion passed unanimously.
Graham Charters: JAVA-161: @Service attributes
"value" and "interfaces" should be combined
Graham Charters: Skipped until Simon available.
Graham Charters: JAVA-1: Accessing SCA Services
from non-SCA component code
Graham Charters: Mike asks what the group thinks
JAVA-1 is trying to achieve.
Graham Charters: One view is this is for allowing
client to be able to connect to multiple different domains.  Whilst
a worthy goal, the design does not address this.
Graham Charters: Mark agrees this does not
cover multiple domains.  Only covers one vendors implementation at
a time.
Graham Charters: Ashok asks whether the multiple
domain goal is worthwhile.
Graham Charters: Bryan thinks the multiple-domain
idea is worthwhile but we might not want to tackle it in 1.1.  There
are some things which need to be considered in an Assembly discussion.
Graham Charters: Anish asks whether we are
limiting connection to a single domain or type of domain.  Mike believes
the design restricts to one type.
Graham Charters: Simon Nash joins the call.
Graham Charters: Dave thinks there are two
different issues: multiple domains from different vendors vs multiple domains
from one vendor.  Dave believes what we have is of value and a good
first step.
Graham Charters: Simon believes the capability
to write code that connects to a provider and is then usable in another
providers environment is a valuable use case.
Graham Charters: Use case: client written to
call into vendor A's domain should be able to also call into vendor A's
domain from vendor B's domain, without change.
Graham Charters: The way the default factory
works in the current proposal prevents the code calling out to vendor A
because the default factory will always be vendor B's.
Graham Charters: It's not essential to be able
to call out to vendor A without know it is calling vendor A.
Graham Charters: Simon stated we could either
fix the default factory or remove.  Both approaches would satisfy
the use case.
Graham Charters: API supports multiple domain
URIs, but all must be to the same vendor.
Graham Charters: Simon thinks we are close
and just need to remove the default factory injection point.
Graham Charters: Mike, the question is what
is the mechanism to acquire the client factory.  We could just require
the vendors to provide them.  Simon, there would be a standard factory
interface.  Vendors the have proprietary mechanisms for locating the
implementation of that standard interface.
Graham Charters: Dave, we don't appear to have
moved the ball forward much because there's still a proprietary API.
Mike Edwards: I suggest that we take this offline
and get another proposal together
Graham Charters: Mike suggests to take offline
and create a more formal proposal.  Simon happy to resend what he
wrote and check it meets the use cases discussed today.
anonymous morphed into anish
Graham Charters: JAVA-161: @Service attributes
"value" and "interfaces" should be combined
Graham Charters: Simon took us through the
proposal
Graham Charters: First part is to remove "interfaces"
and have "value" change its type to an array of classes.
Graham Charters: "name" and "names"
are not affected.
Graham Charters: Next part is to change the
description of the attributes.  Now becomes mandatory to provide "value".
 Simon suggests we could remove the default.
Graham Charters: The reason the default is
there is to allow @Service on its own to be ignored.
Graham Charters: Anish questions why we would
allow this.
Graham Charters: Simon wonders if it's because
we had "interfaces" in the past.
Mark Combellack: combining name and names was
my question
Graham Charters: Anish wonders why we wouldn't
combine "name" and "names".  Simon thinks it might
be confusing.
Graham Charters: I.e. one name in names or
multiple names in name.
Ashok -- I vote for "names"
Graham Charters: +1 (if I had a vote)

Graham Charters: Suggestion is to combine them.
Graham Charters: Simon prefers "name"
because it's more common.  Ashok/Graham prefer names.
Vamsi: I prefer names
Graham Charters: Simon to rewrite the proposal
with "names" and "value" which take arrays.
Graham Charters: JAVA-155: Inconsistent normative
statements in Chapter 10
Martin C next week is not a holiday in ireland
- ours is the week after
Graham Charters: Simon, we're not consistent
about what we saying regarding mapping wsdl-java, java-wsdl, etc.  Some
normative, some not.
Graham Charters: After consideration, only
the Java->WSDL and Java->Schema needs to be defined.  The spec
does not talk about the other direction.
Graham Charters: XML instances coming in need
to be mapped to interface paramters.
Graham Charters: Same issue arises when you
have to map an inbound operation call defined in XML to a Java operation.
Graham Charters: Simon now convinced there
is a use case.  Question is then where should this live.  Mike
believes it's the CAA (want to apply across all implementations).
Graham Charters: Note, this is now section
11 in the public draft.
Graham Charters: Maybe the proposal in the
Jira is suitable.  Mike found a typo (states wsdl to java twice instead
of wsdl to java and java to wsdl).
Graham Charters: Anish, this is very focused
on a particular binding.  For example, you might not get this problem
with binding.sca, but you might get it with binding.ws.  This needs
to be made clear.  It's not about interface mapping.
Graham Charters: Anish not suggesting it belong
in bindings.  It is right for it to live in CAA.
Graham Charters: Simon to try to incorporate
Anish's comment.
Graham Charters: Simon to send updated proposal
to list.
Graham Charters: AOB:
Graham Charters: Close.


Regards,

Graham.



Graham Charters PhD CEng MBCS CITP
STSM, AIM Technical Lead OSGi Expert Groups, Master Inventor, UKI Technical
Staff Member
IBM United Kingdom Limited, MP 146, Hursley Park, Winchester, SO21 2JN,
UK
Tel:  (Ext) +44-1962-816527     (Int) 7-246527   (Fax)
+44-1962-818999
Internet: charters@uk.ibm.com

---

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU