[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Raw chat log of 2009-02-16 telcon
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 13th February 2009
http://www.oasis-open.org/committees/download.php/31226/SCA%20Java%20Minutes%202009-02-13.doc
0. Administration
- Issue Status: Open: 28
1. Review action items:
Action Items that I believe are done:
Action Items that I believe are still to be done:
2008-07-15-02: Plamen to produce a proposal for JAVA-2
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: Simon to raise issue on brain-damaged definition of
@Service annotation (see comments in Nov F2F raw chat log)
2009-02-09-02: SimonN and Mark to work up a better proposal for the
function proposed by Mark for Issue 1
2009-02-13-01: Mike to upload artifacts for JAVA-121 into OASIS Open SVN
2009-02-13-02: Chairs to look at how the files for JAVA-121 should be
licensed
2009-02-13-03: Mark to raise a new issue for the JDK version of the SCA
J spec
2. Blocking issues
All 3 blocking issues are waiting for updated proposals
3. Critical Issue discussion
a. JAVA-60: Sharing Java artifacts across contributions
http://www.osoa.org/jira/browse/JAVA-60
Updated Proposal:
http://lists.oasis-open.org/archives/sca-j/200902/msg00128.html
The remaining 2 critical issues are waiting for updated proposals.
4. New Issues
a JAVA-129: Problems with Example 2b in chapter 7
http://www.osoa.org/jira/browse/JAVA-129
Outline proposal in Jira
b. JAVA-130: CAA - Problems with Example 3 in chapter 7
http://www.osoa.org/jira/browse/JAVA-130
Proposal PDF:
http://lists.oasis-open.org/archives/sca-j/200902/msg00119.html
Proposal MS Word:
http://lists.oasis-open.org/archives/sca-j/200902/msg00118.html
Comments on proposal:
http://lists.oasis-open.org/archives/sca-j/200902/msg00123.html
c. JAVA-131: @Callback injection could be NULL
http://www.osoa.org/jira/browse/JAVA-131
Latest Proposal:
http://lists.oasis-open.org/archives/sca-j/200902/msg00102.html
5. Other Open Issues discussion
a. JAVA-30: "Process" Scope
http://www.osoa.org/jira/browse/JAVA-30
proposal: http://lists.oasis-open.org/archives/sca-j/200812/msg00006.html
b. JAVA-117: Clarify the name implied by setter method for property and
reference names
http://www.osoa.org/jira/browse/JAVA-117
Proposal: http://lists.oasis-open.org/archives/sca-j/200901/msg00124.html
c. JAVA-125: Allow call semantics to be specified in interface.java
Proposal: http://lists.oasis-open.org/archives/sca-j/200902/msg00074.html
d. 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
e. JAVA-102: Need to have a Name parameter on the @Service annotation
proposal: http://www.osoa.org/jira/browse/JAVA-102
f. JAVA-77: A remotable service SHOULD be translatable into a generally
accepted standard for a service, such as WSDL 1.1 or WSDL 2.0
http://www.osoa.org/jira/browse/JAVA-30
proposal: http://lists.oasis-open.org/archives/sca-j/200901/msg00029.html
g. JAVA-76: Incorrect code in section 6.7.4 examples
http://www.osoa.org/jira/browse/JAVA-76
Proposal: http://lists.oasis-open.org/archives/sca-j/200902/msg00098.html
h. JAVA-62: Clarify what a Component Implementation can do with threads
proposal: http://www.osoa.org/jira/browse/JAVA-62
6. Blocking issues waiting for updates/proposals
a. JAVA-104: RFC2119 Language is needed for CAA Specification
http://www.osoa.org/jira/browse/JAVA-104
No proposal
b. JAVA-105: RFC2119 Language is needed for C&I Specification
http://www.osoa.org/jira/browse/JAVA-105
No proposal
c. JAVA-119: JAA Conformance Section
http://www.osoa.org/jira/browse/JAVA-119
Updated proposal:
http://lists.oasis-open.org/archives/sca-j/200902/msg00021.html
Alternative proposal:
http://lists.oasis-open.org/archives/sca-j/200902/msg00049.html
Waiting for email discussion and new proposal
7. Critical issues waiting for updates/proposals
a. JAVA-54: Section 7.1 of the Java CAA Specification is unclear
http://www.osoa.org/jira/browse/JAVA-54
No proposal
b. JAVA-1: Accessing SCA Services from non-SCA component code
http://www.osoa.org/jira/browse/JAVA-1
Proposal: http://lists.oasis-open.org/archives/sca-j/200901/msg00094.html
Source Code Proposal:
http://lists.oasis-open.org/archives/sca-j/200902/msg00050.html
Waiting for updated source code proposal
8. 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)
Pradeep Simha TIBCO Software Inc. (5)
Anish Karmarkar Oracle Corporation (7)
Vamsavardhana Chillakuru IBM (3)
Bryan Aupperle IBM (6)
Plamen Pavlov SAP AG (2)
Ashok Malhotra Oracle Corporation (6)
Simon Nash Individual (4)
Graham Charters IBM (1)
Martin Chapman Oracle Corporation (6)
Yang Lei (4)
Mike Edwards IBM (7)
Meeraj Kunnumpurath Individual (3)
Dave Booz: scribe: Dave (temoporary)
Dave Booz: s/temoporary/temporary
Dave Booz: topic: agenda bashing
Dave Booz: Mark proposes adding 132 to the agenda
Dave Booz: Mike E proposes to add Java 1 to the agenda for discussion -
after java 60
anish back
anish thx
anish dave
Dave Booz: no objections to agenda changes
anish: Topic: approval of minutes
Dave Booz anish, go ahead
anish:
http://www.oasis-open.org/committees/download.php/31226/SCA%20Java%20Minutes%202009-02-13.doc
anish: minutes of 13th feb, 2009 approved
anish: Topic: status
anish: number of open issues 28
anish: topic: AI review
anish: no update to AIs
anish: Topic: Blocking issues
anish: all 3 blocking issues waiting on proposal
anish: Topic: Issue 60
Mike Edwards:
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/31240/sca-javaci-1.1-spec-wd02_issue60g.pdf
anish: Mark: latest proposal from MikeE
anish: MikeE: 3 changes as a response to Simon's points
anish: ... 1st change in section 11 related to export element
anish: ... Simon had pointed out that the working was not clear
anish: ... changed that to read as follows: "The uses directive
indicates that any SCA contribution that imports this package from this
593 exporting contribution MUST also import the same version as is used
by this exporting
594 contribution of any of the packages contained in the uses directive."
anish: this is line 592
anish: simon: that does clear up the ambiguity
anish: MikeE: next change in section 11.2 bullet 2
anish: ... new clause added to the end: "but is always the same
contribution for all imports of the package."
anish: Simon: looks fine
anish: MikeE: final change in 11.3. Had missed a change that we had
previously agreed to
anish: ... new sentence added: "The thread context classloader of a
component implementation class is set to the classloader of its
containing contribution."
anish: Mark: one ed. inconsistency in "classloader" v. "class loader"
anish: Simon: should be consistent through out the spec. Vamsi had
raised this and said it should be a single word
anish: Yang: in section 11.2. Not clear about bullet 2.a
anish: MikeE: The relevant sentence is last line in bullet 2: "If the
java package is not found, continue to step 3."
Vamsi: (class loader. two words in J2SE docs.
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/ClassLoader.html)
anish: Motion: m: MikeE s: SimonN Resolve issue 60 using the document at
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/31240/sca-javaci-1.1-spec-wd02_issue60g.pdf
with the ed change suggested to section 11.2
anish: Motion approved w/o
anish: MikeE: Vamsi has noticed that "class loader" is two words except
for the actual class name which is "ClassLoader". Will handle that as
editorial
anish: ACTION: MikeE: to fix the usage of "class loader" through out the
spec
anish: Topic: Issue Java-1
anish: http://osoa.org/jira/browse/Java-1
anish: Accessing SCA Services from non-SCA component code
anish: MikeE: don't want client-side dependency on
implementation-specific code
anish: ... discussion on builder to provider access to
implementation-specific code. The Q is to figure out how to do this.
anish: ... I had suggested that we look at DOMFactory
anish: ... want to see if we agree on a direction here
anish: SimonN: taken what Mark had suggested (SCAClientFactory) and
suggested that instead of having it code defined make it spec defined.
Have OASIS provide a ref. implementation but not required. With RFC 2919
keywords to say what it must/must not do
anish: ... MikeE had suggested an abstract base class. Don't have a
strong opinion on it. Need a level of indirection
anish: Mark: happy with Simon's suggestion
anish: MikeE: I quite like how XML gets hold of factories with an
abstract base class
Vamsi: s/RFC 2919/RFC 2119
anish: ... the standard code will have a simple set of mechanism for
finding the factories. The Q is whether to have a default
anish thx Vamsi
anish: ... in our case no obvious default
anish: ... might want to just fail
anish: MikeE: the distinction is that a provider can subclass
anish: Simon: in JAXB there is a hardwired factory. I think this should
be replaceable. We should not have a concrete implementation for finding
the factory, that everyone must use
Mark Combellack lowered your hand
anish: Anish: how does it find the actual implementation class: std
property?
anish: MikeE: same as JAXP
anish: SimonN: the abstract class would contain a particular factory
finder impl, that cannot be overriden by a vendor
anish: MikE: trade off here
anish: SimonN: worried about things like being OSGi friendly
anish: s/MikE/MikeE/
anish: MikeE: worried about client code being dependent on an particular
vendor code
anish: SimonN: agree that the client code should not depend on vendor
code, but it is the particular implementation of factory finder mandated
by the standard that i'm worried about
anish: SimonN: does anyone care if the standard method (eg newInstace())
should be part of the interface/abstract class?
anish: Jim: in the interface where would the finder method be: a static
block?
anish: SimonN: in both cases, there would be class with an impl.
(static). The difference is would there be a separate interface as well.
Two options: vendor could either extend the abstract base class or
implement a particular interface
jeffm: hi, that was me joining the call
anish: Jim: will have to think/look more about this
anish: Mark: at this point, we need some code
anish: ACTION: Mark to create code to contrast the two options for
direction for issue Java-1
anish: Topic: New Isses
anish: s/Isses/Issues/
anish: JAVA-129: Problems with Example 2b in chapter 7
http://www.osoa.org/jira/browse/JAVA-129
Outline proposal in Jira
anish: SimonN explains issue 129
anish: 4 points in the issue
anish: free floating service definitions
anish: operation elements inside a service has been removed
anish: operation elements are incorrectly placed
anish: incorrect intent inheritance
Vamsi: Simon, that was funny
anish: MOTION: m:SimonN s:Vamsi open issue 129
anish: motion approved w/o
anish: JAVA-130: CAA - Problems with Example 3 in chapter 7
http://www.osoa.org/jira/browse/JAVA-130
Proposal PDF:
http://lists.oasis-open.org/archives/sca-j/200902/msg00119.html
Proposal MS Word:
http://lists.oasis-open.org/archives/sca-j/200902/msg00118.html
Comments on proposal:
http://lists.oasis-open.org/archives/sca-j/200902/msg00123.html
anish: SimonN: we have already talked about this on a call
anish: ... number of problems with Example 3 in section 7.6.2.1 of
cd02-rev2.
anish: MOTION: m:SimonN s:Vamsi open issue 130
anish: motion approved w/o
anish: JAVA-131: @Callback injection could be NULL
http://www.osoa.org/jira/browse/JAVA-131
Latest Proposal:
http://lists.oasis-open.org/archives/sca-j/200902/msg00102.html
anish: DaveB explains his issue
anish: DaveB: some corner cases such as an implementation implements
interfaces that are both bidirectional and non-bidirectional
anish: MOTION: m:DaveB s:MikeE open issue 131
anish: motion approved w/o
anish: Java 132: Specification should require JDK 1.5 or above
anish: Mark: the spec allows JDK 1.4
anish: ... we have stated that we'll be compiling with JDK 1.5 and our
APIs contain generics and annotations
anish: MOTION: m:Mark slamen open issue 132
anish: motion approved w/o
anish: Topic: Issue 30
anish: JAVA-30: "Process" Scope
http://www.osoa.org/jira/browse/JAVA-30
proposal: http://lists.oasis-open.org/archives/sca-j/200812/msg00006.html
anish: DaveB: issue originally opened as process scope. We ran into
difference of opinion on this. A "composite" scope component in a
cluster -- is there one instance or multiple
anish: ... we had an initial proposal from MikeE, some of the text in
this proposal is from MikeE. His proposal was that "composite" scope
should be a solution to this problem and we should not introduce a
"process" scope
anish: ... composite scope at domain-level is a singleton, at
lower-level, depends on how many times the composite gets used
Mark Combellack lowered your hand
anish: Anish: so case (a) and case (b) are the same wrt behavior of the
runtime
anish: DaveB: yes. mostly because this was meant to address the
"process" scope Q
anish: Anish: if there is just one use of a composite, in a cluster, how
many instances would there be?
anish: DaveB: one
anish: SimonN: logical or physical?
anish: DaveB: one instance as seen by the consumer
anish: Anish: i meant logical
anish: MikeE: In the proposal ("a) Where the composite containing the
component using the Java implentation is the SCA Domain (ie a deployment
composite declares the component using the implementation)") change
"i.e." to "e.g."
anish: Bryan: there is an AI against Jim/Mark/Mike to generate usecases
Vamsi: typo on line 154 implentation - implementation
anish: Mark: i have come around to Dave's POV
anish: Motion: m:DaveB s: resolve Java-30 with the proposal at
http://lists.oasis-open.org/archives/sca-j/200812/msg00006.html with one
ed change (s/ie/eg/)
anish: motion approved w/o
anish: Topic: issue 117
anish: JAVA-117: Clarify the name implied by setter method for property
and reference names
http://www.osoa.org/jira/browse/JAVA-117
Proposal: http://lists.oasis-open.org/archives/sca-j/200901/msg00124.html
anish: Vamsi: this is an issue raised against java c&i but affects both
c&i and CAA. Do we need another issue?
anish: Mark: we should have a second issue. but lets see where this goes
and make a late decision on this
anish: Vamsi walks thru sca-javaci-1.1-spec-wd02+Issue117.doc changes
(from the proposal)
anish: Vamsi: 1st change in section 8
anish: In line 392
anish: Vamsi: same section, similar change for properties on line 418
anish: ... similar change on lines 479, 492 in section 8.2
anish: ... section 8.3 -- new section
anish: ... describes what must happen if there are two setter methods
with same JavaBean prop name
anish: SimonN: the example distinguishes based on the case of 's'
(someProperty). I missed that. Can we added a comment to point that out.
anish: Vamsi: will move next to the CAA spec
sca-javacaa-1.1-spec-cd02+Issue117.doc in the proposal msg
anish: ... 1st change in 8.14 1387
anish: ... 2nd change in 8.15 1454
anish: ... added a ref to JavaBeans spec
anish: MOTION: m:Vamsi s:DaveB resolve issue 117 based on the proposal
at http://lists.oasis-open.org/archives/sca-j/200901/msg00124.html
anish: motion approved w/o
anish: anish: 117 affects both specs and if we produce the CDs at
different times this may be problematic
anish: Mark: would encourage the editors to produce the two CDs at the
same time
anish: Bryan: is the next one that we vote on the PRD
anish: Dave: I hope so
anish: Bryan: if so, this won't be a big problem wrt book keeping
Dave Booz Anish, do you have a C&I draft in progress right now?
anish: Vamsi: simon's comment about ed changes to "someProperty"
anish: ACTION: editors to make an ed change when applying resolution of
issue 117 (in section 8.3) to make a comment about the case difference
in "someProperty/SomeProperty"
anish dave, i don't
anish would be happy to help out, if you want to do divide-and-conquer
anish: Mark: AOB and straggler roll
anish: no AOB
anish: meeting adjourned
anish dave, can make updates without divide-and-conquer as well
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]