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: Java TC raw minutes June 22nd 2009

Mark Combellack: - Roll Call
- Appointment of scribe. List attached below
- Agenda bashing
- Approval of minutes for 19th June 2009

0. Administration
- Issue Status: Open: 26
- SCA-J Public Review
   Started: 8th June 2009
   Ends:    7th August 2009

1. Review action items:

Action Items that I believe are done:
2009-06-19-01: Anish to raise an issue against the SCA Spring spec to add support for SCA annotations in Spring Beans

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-06-01-01: MikeE to raise issue regarding some Assembly tests that require Java
2009-06-05-02: Anish to raise an issue in Bindings TC against WS binding spec to address wireFormat and operationSelector pseudo-schema once the Assembly change is made to make these abstract.
2009-06-19-01: Mike E to prepare a detailed proposal for Issue 149

2. New Issues

a. JAVA-125: Allow call semantics to be specified in interface.java
Request to re-open this issue. See:

3. Open Issues

a. JAVA-139: Default value for SCA property is not supported for java implementations
Outline of proposal in Jira
Latest discussion:

b. JAVA-153: Java CI should have corresponding changes in JAVA-125
Latest proposal (rev 4):

c. JAVA-131: @Callback injection could be NULL (expanded to include refs, property and re-injection and callback
Latest proposal:

4. Issues waiting for updated proposals

a. JAVA-46: equals() method on ServiceReference and CallableReference
Waiting for updated proposal

b. JAVA-1: Accessing SCA Services from non-SCA component code
Latest discussions:
Updated Proposal:
Updated Proposal (PDF):
Waiting for updated proposal

c. JAVA-155: Inconsistent normative statements in Chapter 10
Discuss - What do we do next?
Waiting for updated proposal

d. JAVA-127: Long running request/response operations
Waiting for presentation slides

5. Issues without proposals

a. JAVA-13: ComponentContext.getProperty(...) ill defined
No proposal

b. JAVA-51: More examples on <interface.wsdl> mapping to Java
No proposal

c. JAVA-54: Section 7.1 of the Java CAA Specification is unclear
No proposal

d. JAVA-62: Clarify what a Component Implementation can do with threads
No proposal

e. JAVA-78: Need API to set EPR and for a reference invocation
No proposal

f. JAVA-156: Intent annotations are missing from Java CAA as compared to Policy FW spec
No proposal

6. 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 (3)
Anish Karmarkar Oracle Corporation (12)
Martin Chapman Oracle Corporation (10)
Ashok Malhotra Oracle Corporation (11)
Bryan Aupperle IBM (12)
Yang Lei (8 )
Simon Nash Individual (9)
Mike Edwards IBM (11)

Graham Charters: Scribe: Graham Charters
Dave Booz: quorum with 54% 6 of 11
Graham Charters: Agenda Bashing:
Graham Charters: No comments.  Going with agenda as posted.
Graham Charters: Minutes Approval:
Graham Charters: No comments.  Approved as posted.
Graham Charters: Administration:
Graham Charters: 26 open issue.  Public review to end 7th Aug.
Graham Charters: 1 action complete.  To be added to Friday agenda (Spring use of Java annotations).
Graham Charters: New Issues:
Graham Charters: Java-125 re-opening...  Don't have 2/3 majority to do this.  Deferred to later.
Graham Charters: Open Issues:
Graham Charters: Java-139
Graham Charters: Email from Simon: http://lists.oasis-open.org/archives/sca-j/200906/msg00092.html
Graham Charters: Started looking more deeply at how the default value can be done.  Unfortunately, can be of many types.  Annotations constrain the things which can be put in as values.
Graham Charters: Simon came up with proposal which support all possible property types.  Dave made the suggestion that the problems really is we have the wrong default value.
Graham Charters: Default value for 'require' that is.  Suggestion to change the default for required to false.
Graham Charters: Mike suggest closing no action.  Anish agreed.  Feeling was the 'required' default was an orthogonal issue.
Graham Charters: Anish asked if there was any benefits to doing this for just scalars, thus not pulling in all the complexity.
Graham Charters: Dave concerned it opens the door for more complex things in the future...
Graham Charters: Anish thinks most of these values will be 'string' (so if we do it, it needs to be scalar + string).
Graham Charters: Simon asks, what if we do it just for strings and nothing else.  Strings are what would show up in the component Type.
anonymous morphed into anish
Graham Charters: Mike still not convinced.  Doesn't see the benefit.  Simon think the benefit is it becomes part of the CT and helps with configuring a composite.
Graham Charters: Proposing 1 attribute called "defaultValue" with no type (always string).  It's type would be handled as if it has been set in the component type.
Graham Charters: Action: Simon to write the proposal for the 'defaultValue' attribute only accepting strings.
Graham Charters: Java-153:
Graham Charters: Proposal from Simon:  http://lists.oasis-open.org/archives/sca-j/200906/msg00117.html
Graham Charters: Rev 4 adds a new example to show the reflected CT.
Graham Charters: Mark: second example shows no remoteable attribute, but the @Remotable annotations.  This is valid because the XML does not need to duplicate what is in the annotation.
Graham Charters: Currently only require an explicit setting if the value is to be changed.
Graham Charters: Mark suggests adding a paragraph just to explain this.
Graham Charters: Added paragraph in section 3.1 (not normative).
Graham Charters: Next change is in Section 8 (normative)
Graham Charters: There is no use case for remotable="false" - no-op if interface does not have remotable, and it's an error if it does.  We could sub-type to not allow false.
anish when are spec wonks considered human?
Mike Edwards: ....never
Graham Charters: Also added text for the reference side.
Graham Charters: Also added text to 8.1 to say always omitted.
Graham Charters: To wonk is human; to forgive, divine.
Graham Charters: Same for 8.2.  Never a need to specify the remotable attribute.
Mark Combellack: The interface specified in the interface.java is implictly remotable because the implementation class contains @Remotable
Graham Charters: The interface specified in interface.java is already implicitly remotable because the HelloServiceImpl already contains the @Remotable attribute.
anonymous morphed into Pradeep
Simon Nash: The following snippet shows the introspected component type for this implementation.
<?xml version="1.0" encoding="UTF-8"?>
<componentType xmlns="
<service name="HelloService">
<interface.java interface="services.hello.HelloService"/>

Simon Nash: the above is location A
Simon Nash: The following snippet shows the introspected component type for this implementation.
<?xml version="1.0" encoding="UTF-8"?>
<componentType xmlns="
<service name="HelloServiceImpl">
<interface.java interface="services.hello.HelloServiceImpl"/>

Simon Nash: above text is location B
Graham Charters: Proposal: Add the following text, "The interface specified in the interface.java is implicitly remotable because the interface contains @Remotable" at location A
Simon Nash: Add the following text, "The interface specified in the @interface attribute of the <interface.java/> element is implicitly remotable because the Java interface contains @Remotable" at location A
Mark Combellack: Looks ok to me
Simon Nash: Add the following text, "The interface specified in the @interface attribute of the <interface.java/> element is implicitly remotable because the Java implementation class contains @Remotable" at location A
Graham Charters: second one is location B
Mark Combellack: +1
Graham Charters: Simon moves to resolve issue 153 with the changes in rev 4 + the 2 proposed changes in the chat room (at locations A & B).
Graham Charters: Mike Edwards seconds.
Graham Charters: Passed with unanimous consent.  153 is resolved.
Graham Charters: Java 125:
Graham Charters: See http://lists.oasis-open.org/archives/sca-j/200906/msg00099.html
Graham Charters: Dave commented we hadn't got the text right.
Graham Charters: Was correct at the time, but have added new places where @Remotable annotation can be added, and in these cases the the @remotable attribute is not an alternative, it's equivalent.
Graham Charters: Motion: Simon moves to re-open Java-125.
Graham Charters: Dave Booz seconds.
Graham Charters: Motion passed with unanimous consent.  Java-125 is re-opened.
Graham Charters: Proposal included in msg00099.
Graham Charters: Proposal is to change 2 sentences as described in msg00099.
Graham Charters: Motion: Simon moves to resolve the issue with the proposal in msg00099.
Graham Charters: Mike Edwards seconds.
Graham Charters: Motion passed with unanimous consent.  Java-125 is resolved...again
Graham Charters: Java-131:
Graham Charters: Proposal from Simon: http://lists.oasis-open.org/archives/sca-j/200906/msg00119.html
Graham Charters: Specified 3 new normative statements.
Graham Charters: 1 & 2 are in new section 7.2.3.
anish: q
Graham Charters: 3 is in section 10.3 [JCA90055]
anish: can it be a subtype?
anish give me just a sec
Simon Nash: can't hear you
Simon Nash: ok
Graham Charters: The type of the method being a subtype of what is required by the bi-direction interface (a subtype in the Java sense).
Graham Charters: Simon believe the proxy being injected would not be sufficient because it would not contain any extra methods specified on the subtype.
Graham Charters: Use case: component impl has forward interface A and callback iface B.  Redefine interface for service at the component level.  Make them compatible subsets A' and compatible superset B'.  Then wire up to a calling component with A' and B'.
Graham Charters: use cases is adding some new facility to the callback interface B'.  Would like to know if the client has this new capability.
anish happy with that as well
Graham Charters: Mike believes this is outside the scope of 131.  It would need to be covered by general references.
Mark Combellack: Warning: approx 5 minutes left
Graham Charters: Motion: Simon moves to resolve 131 with the changes in the doc attatched to msg00119.
Graham Charters: Seconded by Mike Edwards
Graham Charters: Motion passed unanimously.  Java-131 is resolved.
Graham Charters: AOB:
Graham Charters: None.
Graham Charters: Meeting closed...



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

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