[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-j] Raw chat log of 2008-11-11 ALL DAY
Mark Combellack: 9:00 to 9:15 Welcome
Roll call
Appointment of scribe for day 1
Agenda bashing
Approval of minutes of 3rd November call
http://www.oasis-open.org/committees/download.php/29906/SCA%20Java%20Minutes%202008-11-03.doc
9:15 - 9:30 Accepting new issues
None at the moment
9:30 - 10:40 Local Interfaces, pass by reference and multiple services
JAVA-56 When more than one interface with the same unqualified name used in the @Service annotation
Proposal at http://lists.oasis-open.org/archives/sca-j/200811/msg00006.html
JAVA-3 Local services expose implementation classes as their type
No proposal but some discussion
http://lists.oasis-open.org/archives/sca-j/200808/msg00098.html
JAVA-6 @AllowsPassByReference requires more detailed description
No proposal some suggestions in Jira
10:40 - 11:00 Break
11:00 - 11:02 2 Minutes silence for Remembrance Day
See http://en.wikipedia.org/wiki/Remembrance_Day#United_Kingdom
11:02 - 12:45 Scopes and Package names
JAVA-28 Package Name Changes
http://lists.oasis-open.org/archives/sca-j/200811/msg00017.html
JAVA-21 Clarify Request Scope lifetime
Proposal in Jira and http://lists.oasis-open.org/archives/sca-j/200811/msg00005.html
Previous discussions at http://lists.oasis-open.org/archives/sca-j/200803/msg00034.html
JAVA-30 "Process" Scope
Proposal in Jira and at http://lists.oasis-open.org/archives/sca-j/200807/msg00068.html
12:45 - 1:45 Lunch
1:45 - 3:40 Callbacks
JAVA-25 Callback Simplification
Proposals at http://lists.oasis-open.org/archives/sca-j/200803/msg00063.html
and http://lists.oasis-open.org/archives/sca-j/200809/msg00089.html
Some discussion at http://lists.oasis-open.org/archives/sca-j/200804/msg00035.html
JAVA-67 Need normative rules for stateful callbacks
No proposal
JAVA-69 Misleading statement about lifetime of stateful callbacks
(Pending proposal from Simon)
JAVA-19 Redirecting callbacks
Proposal in Jira
JAVA-73 Incorrect reference to "original request"
Proposal in Jira
JAVA-52 RequestContext.getCallbackReference() description inadequate
Proposal in Jira
JAVA-74 Clarify meaning of "should implement"
No proposal
JAVA-76 Incorrect code in section 6.7.4 examples
(Pending proposal from Simon)
3:40 4:00 Break
4:00 - 6:00 Callbacks (continued)
6:00 Adjourn
Ashok: test
anish: scribe: anish
anish: Topic: agenda bashing
anish: Jim is interested in callback/conversation, so will delay it by an hour
anish: callback/conversation topic will be reordered
anish: agenda approved with one change
anish: Topic: approval of minutes from 2008-11-03
anish:
http://www.oasis-open.org/committees/download.php/29906/SCA%20Java%20Minutes%202008-11-03.doc
anish: minutes approved w/o
anish: Topic: new issues
anish: no new issue
anish: s/issue/issues
anish: Topic: Issue 56
anish: JAVA-56 When more than one interface with the same unqualified name used in the @Service
annotation
Proposal at http://lists.oasis-open.org/archives/sca-j/200811/msg00006.html
anish: Mark explains the issue
anish: ... and the proposal
Mark Combellack: If a Java implementation needs to realize two services with the same interface or
two services with the different interfaces that have the same simple class name, then this is
achieved through subclassing of the interface.
Mark Combellack: If a Java Implementation defines a @Service annotation that lists two interfaces
with the same simple class name, the SCA Runtime MUST not deploy that Component
Mark Combellack: Add words between the *** to the paragraph on line 1687:
If a Java implementation needs to realize two services with the same interface *** or two services
with different interfaces that have the same simple name, *** then this is achieved through
subclassing of the interface.
Add the following extra paragraph before line 1690:
If a Java Implementation defines a @Service annotation that lists two interfaces with the same
simple name, the SCA Runtime MUST not deploy that Component
Mark Combellack: Add words between the *** to the paragraph on line 1687:
If a Java implementation needs to realize two services with the same interface *** or two services
with different interfaces that have the same simple name, *** then this is achieved through
subclassing of the interface.
Add the following extra paragraph before line 1690:
If a Java Implementation defines a @Service annotation that lists two interfaces with the same
simple name, the SCA Runtime MUST NOT deploy that Component
Mark Combellack: It is not possible for Components to have Services with the same Java simple name.
Mark Combellack: It is not possible a Components to have more than one Service with the same Java
simple name.
Mark Combellack: It is not possible a Component to have more than one Service with the same Java
simple name.
Mark Combellack: It is not possible for a Component to have more than one Service with the same
Java simple name.
anish: A Component MUST NOT have two Services with the same Java simple name.
Mark Combellack: If a Java implementation needs to realize two services with the same simple name
then this can be achieved through subclassing of the interface.
anish: A component MUST NOT have two services with the same Java simple name.
Mark Combellack: If a Java implementation needs to realize two services with the same Java simple
name then this can be achieved through subclassing of the interface.
Mark Combellack: Replace paragraph at 1687-1689 with:
A component MUST NOT have two services with the same Java simple name. If a Java implementation
needs to realize two services with the same Java simple name then this can be achieved through
subclassing of the interface.
anish: Mark moves Anish Seconds to resolve issue 56 by replacing paragraph at 1687-1689 in CAA CD01
spect with:
anish: A component MUST NOT have two services with the same Java simple name. If a Java
implementation needs to realize two services with the same Java s
anish: imple name then this can be achieved through subclassing of the interface.
Dave Booz: ping
anish: motion approved w/o
anish: Resolution: issue 56 is resolved with the above motion
anish: Topic: Issue 3
anish: JAVA-3 Local services expose implementation classes as their type
No proposal but some discussion
http://lists.oasis-open.org/archives/sca-j/200808/msg00098.html
Mark Combellack: More discussions at:
http://lists.oasis-open.org/archives/sca-j/200810/msg00039.html
anish: Discussion on addition of @Local annotation.
anish: @Local can be used in an interface, whereas @service has to be in the impl class
Mark Combellack: Breaking until 11:20
Mark Combellack: Resuming
anish: Action: SimonN to raise 3 issues for each C&I wrt what happens if the annotation rules are
not followed (SCA runtime MUST NOT deploy the component)
anish: Simon moves Dave seconds to close issue 3 with no action
anish: motion approved w/o
anish: Resolution: Issue 3 is closed with no action
anish: Topic: Issue 6
anish: JAVA-6 @AllowsPassByReference requires more detailed description
No proposal some suggestions in Jira
anish: MikeE: two ways: a) get rid of the annotation, OR b) allow the same annotation for the
reference (on the client side)
anish: Action: MikeE to raise an issue in Assembly regarding @AllowPassByReference
anish: Mark: do we have consensus on a direction for this
anish: Action: Simon to provide proposal for issue 6
anish: Topic: issue 28
anish: Mary has come back and suggested org.oasisopen but has said that it is not necessary for
OASIS to own this
anish: General consensus that this does not make sense
anish: Anish moves Simon seconds that using org.oasisopen without OASIS acquiring ownership of the
domain does not make sense. And if OASIS is not willing to buy this domain we prefer to continue
with the org.osoa package name
anish: motion approved w/o
anish: Action: Dave to draft email to raise an objection to TC admin decision
anish: Lunch
anish: resume @ 1:30pm
Simon Nash: Want some bad advice?
Most people believe that moss and lichens grow on the northeast side of trees. Fundamentally
speaking in a perfect
world moss and lichens would only
grow on the northeast side of
trees or rocks. The problem is they will
grow in any cool area that gets very little
direct sunlight and retains a lot of
moisture. In an area that is heavily
forested, or where natural formations
block warming sunlight and drying
winds, moss and lichens can thrive.
What is the best advice? Have an
accurate map and a
compass and know
how to use them.
Learn other natural
navigation
techniques, including
how to use an analog
watch to find south or
following the stars.
Martin C : Scribe: Martin C
Martin C : Topic: Issue 1
Martin C : Mike E goes through his presentation:
http://www.oasis-open.org/apps/org/workgroup/sca-j/email/archives/200811/msg00032.html
Martin C : Discussion took place as to whether this proposal satisfies the use cases. Acknowleged
that there are different use cases, and some other proposals dont cover them all, which Mike E's
does.
Dave Booz: Was that Jim that joined the call?
anonymous: yes
Dave Booz: Jim, I've got your attendance recorded
Jim Marino: thx
Martin C : Some discussion on the nature of the api.
Martin C : Some support for it to be createAnonComponent on the domainContext
Jim Marino: when it is appropriate, I'd like to comment on passing an implementation instance in
for the API
Dave Booz: ok
Dave Booz: i haven't forgotten you Jim
Martin C : discussion of another api that can be used in combo with createcomponent
Martin C : ServiceRef<interfacetype> = doimainContext.getReference("componentName/ServiceName",
interafcetype)
Martin C : Option 1: a getrefrence api that may also set the callback to the impl
Martin C : option 2: create an anonymous/insible conponet in the domain (can't have deploy service)
Martin C : option 3: create/deploy a bone-fide full capability component
anish: Option 0: a getRefererence api that does not support services or callbacks
Martin C : There was most support for 0 or 1. There was some support for option3
Martin C : there was little support for option 2
Martin C : People can live with eliminating option 2., so its gone
Martin C : Jim if you do 3 then do the whole management job of delete update etc
Martin C : Need two proposals for the two cases.
Martin C : Mike E will write up option 3
Martin C : strike the above
Martin C : Mike E and Dave B will write up one proposal to cover options 0, 1 and 3
Martin C : ACTION: Mike E and Dave B, to write up a proposal to JAVA-1 covering the options decided
at the Nov F2F
Martin C : Topic: JAVA-25
Simon Nash: http://www.oasis-open.org/apps/org/workgroup/sca-j/email/archives/200809/msg00089.html
Martin C : http://www.osoa.org/jira/browse/JAVA-25
Martin C : Simon goes through his mail msg00089
Martin C : Only talking about the non-coversational callback case.
Martin C : break for 20 mins
Make your own tea
Mark Combellack: Venue for tonights dinner - http://www.positanocardiff.com/
Mark Combellack: Table booked for 7:00 to 7:30
Mark Combellack: Postcode is CF10 1BG
Martin C : Resuming after break
Martin C : Lively discussion on Simon's email
Martin C : Debate on infrastructure vs application correlation
Martin C : requirement that service and client needs to understand which request a call-back is a
response to
Martin C : Discussion on a thread safe mechanism for crateing an ID that can be sent allong with a
message to help with correlation
Martin C : There will be a burden on the bindings to carry this ID
Martin C : The ID is for a one time invocation
Mark Combellack lowered your hand
Martin C : Discussion on how to ease the burden on the client side
Martin C : Discussion on how to ease the burden on the client side
Martin C : Discussion on how to ease the burden on the client side
Martin C : If this id was binding indepentant can use differnt binding on the call-back
Martin C : Option 1: Do not talk about message correlation, define rules for the server, but say
that if a client wants message correlation they need to worry about this in business data
Martin C : Option 2: Provide a means to carry a binding indepent message id that can be used by
both server and clent. Use of this id would be optional/chooseable for a client
Martin C : s/message id/interaction
Martin C : There was more support for option 1.
Martin C : ACTION: Simon N, write up a propsal outlining spec changes needed to not support message
correllation on callbacks
Martin C : for JAVA-25
Martin C : ACTION: Mark C, to proposae a delta to Simon's action on JAVA-25, to add support for
message corellation on callbacks
Martin C : Topic: Java-67
Martin C : Simon N already has an action for this
Martin C : http://www.osoa.org/jira/browse/JAVA-67
Martin C : Topic: JAVA-19: http://www.osoa.org/jira/browse/JAVA-19
Martin C : Discuss outline porposal in java-19
Martin C : Simon proposals that we agree a direction by removing the capability to customise the
call back as described in 6.7.5, and related knock on edits
Martin C : Motion by Simon, Dave B 2nds
Martin C : passed W/O
Martin C : ACTION: Simon N, write spec change proposal to resolve JAVA-19 as dirceted at the Nov
F2F
Martin C : s/dircet/direct/
Martin C : Topic: JAVA-73: http://www.osoa.org/jira/browse/JAVA-73
Simon Nash: ... invoke the operation on the callback interface
Simon Nash: ... service reference for the callback interface
Martin C : in section 6.7.4
anish: On the client side, the object returned by the getServiceReference() method represents the
service reference for the callback interface
anish: On the client side, the object returned by the getServiceReference() method represents the
service reference for its callback interface
Simon Nash: ... the interface through which the callback was made
Simon Nash: On the client side, the object returned by the getServiceReference() method represents
the service reference for the interface through which the callback was made
Simon Nash: On the client side, the object returned by the getServiceReference() method represents
the service reference through which the callback was made
Simon Nash: On the client side, the object returned by the getServiceReference() method represents
the service reference for the callback
Simon Nash: On the client side, the object returned by the getServiceReference() method represents
the service reference for the callback to the client
Simon Nash: On the client side, the object returned by the getServiceReference() method represents
the service reference for the callback
Martin C : Motion from Anish: Resolve JAVA-73, by changing 1st sentenec of last paragarph in 6.7.4
to !
Martin C : s/!/" On the client side, the object returned by the getServiceReference() method
represents the service reference for the callback"
Martin C : 2nd by Simon N
Martin C : Motion passed w/o
Martin C : Motion to recess
> -----Original Message-----
> From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com]
> Sent: 11 November 2008 13:40
> To: OASIS Java
> Subject: [sca-j] Raw chat log of 2008-11-11 morning session
>
>
> Mark Combellack: 9:00 to 9:15 Welcome
> Roll call
> Appointment of scribe for day 1
> Agenda bashing
> Approval of minutes of 3rd November call
>
> http://www.oasis-open.org/committees/download.php/29906/SCA%20
Java%20Minutes%202008-11-03.doc
>
>
> 9:15 - 9:30 Accepting new issues
> None at the moment
>
> 9:30 - 10:40 Local Interfaces, pass by reference and multiple
> services JAVA-56 When more than one interface with the same
> unqualified name used
> in the @Service annotation
> Proposal at
> http://lists.oasis-open.org/archives/sca-j/200811/msg00006.html
>
> JAVA-3 Local services expose implementation classes as their
> type No proposal but some discussion
> http://lists.oasis-open.org/archives/sca-j/200808/msg00098.html
>
> JAVA-6 @AllowsPassByReference requires more detailed
> description No proposal some suggestions in Jira
>
>
> 10:40 - 11:00 Break
>
>
> 11:00 - 11:02 2 Minutes silence for Remembrance Day
> See http://en.wikipedia.org/wiki/Remembrance_Day#United_Kingdom
>
>
> 11:02 - 12:45 Scopes and Package names
> JAVA-28 Package Name Changes
> http://lists.oasis-open.org/archives/sca-j/200811/msg00017.html
>
> JAVA-21 Clarify Request Scope lifetime
> Proposal in Jira and
> http://lists.oasis-open.org/archives/sca-j/200811/msg00005.html
> Previous discussions at
> http://lists.oasis-open.org/archives/sca-j/200803/msg00034.html
>
> JAVA-30 "Process" Scope
> Proposal in Jira and at
> http://lists.oasis-open.org/archives/sca-j/200807/msg00068.html
>
>
>
> 12:45 - 1:45 Lunch
>
> 1:45 - 3:40 Callbacks
> JAVA-25 Callback Simplification
> Proposals at
> http://lists.oasis-open.org/archives/sca-j/200803/msg00063.html
> and http://lists.oasis-open.org/archives/sca-j/200809/msg00089.html
> Some discussion at
> http://lists.oasis-open.org/archives/sca-j/200804/msg00035.html
>
> JAVA-67 Need normative rules for stateful callbacks
> No proposal
>
> JAVA-69 Misleading statement about lifetime of stateful
> callbacks (Pending proposal from Simon)
>
> JAVA-19 Redirecting callbacks
> Proposal in Jira
>
> JAVA-73 Incorrect reference to "original request"
> Proposal in Jira
>
> JAVA-52 RequestContext.getCallbackReference() description
> inadequate Proposal in Jira
>
> JAVA-74 Clarify meaning of "should implement"
> No proposal
>
> JAVA-76 Incorrect code in section 6.7.4 examples
> (Pending proposal from Simon)
>
>
> 3:40 4:00 Break
>
> 4:00 - 6:00 Callbacks (continued)
>
> 6:00 Adjourn
>
> Ashok: test
>
> anish: scribe: anish
>
> anish: Topic: agenda bashing
>
> anish: Jim is interested in callback/conversation, so will
> delay it by
> an hour
>
> anish: callback/conversation topic will be reordered
>
> anish: agenda approved with one change
>
> anish: Topic: approval of minutes from 2008-11-03
>
> anish:
> http://www.oasis-open.org/committees/download.php/29906/SCA%20
Java%20Minutes%202008-11-03.doc
>
> anish: minutes approved w/o
>
> anish: Topic: new issues
>
> anish: no new issue
>
> anish: s/issue/issues
>
> anish: Topic: Issue 56
>
> anish: JAVA-56 When more than one interface with the same unqualified
> name used in the @Service annotation
> Proposal at
> http://lists.oasis-open.org/archives/sca-j/200811/msg00006.html
>
> anish: Mark explains the issue
>
> anish: ... and the proposal
>
> Mark Combellack: If a Java implementation needs to realize
> two services
> with the same interface or two services with the different interfaces
> that have the same simple class name, then this is achieved through
> subclassing of the interface.
>
> Mark Combellack: If a Java Implementation defines a @Service
> annotation
> that lists two interfaces with the same simple class name, the SCA
> Runtime MUST not deploy that Component
>
> Mark Combellack: Add words between the *** to the paragraph
> on line 1687:
>
> If a Java implementation needs to realize two services with the same
> interface *** or two services with different interfaces that have the
> same simple name, *** then this is achieved through
> subclassing of the
> interface.
>
>
> Add the following extra paragraph before line 1690:
>
> If a Java Implementation defines a @Service annotation that lists two
> interfaces with the same simple name, the SCA Runtime MUST not deploy
> that Component
>
> Mark Combellack: Add words between the *** to the paragraph
> on line 1687:
>
> If a Java implementation needs to realize two services with the same
> interface *** or two services with different interfaces that have the
> same simple name, *** then this is achieved through
> subclassing of the
> interface.
>
>
> Add the following extra paragraph before line 1690:
>
> If a Java Implementation defines a @Service annotation that lists two
> interfaces with the same simple name, the SCA Runtime MUST NOT deploy
> that Component
>
> Mark Combellack: It is not possible for Components to have
> Services with
> the same Java simple name.
>
> Mark Combellack: It is not possible a Components to have more
> than one
> Service with the same Java simple name.
>
> Mark Combellack: It is not possible a Component to have more than one
> Service with the same Java simple name.
>
> Mark Combellack: It is not possible for a Component to have more than
> one Service with the same Java simple name.
>
> anish: A Component MUST NOT have two Services with the same
> Java simple
> name.
>
> Mark Combellack: If a Java implementation needs to realize
> two services
> with the same simple name then this can be achieved through
> subclassing
> of the interface.
>
> anish: A component MUST NOT have two services with the same
> Java simple
> name.
>
> Mark Combellack: If a Java implementation needs to realize
> two services
> with the same Java simple name then this can be achieved through
> subclassing of the interface.
>
> Mark Combellack: Replace paragraph at 1687-1689 with:
>
> A component MUST NOT have two services with the same Java
> simple name.
> If a Java implementation needs to realize two services with the same
> Java simple name then this can be achieved through subclassing of the
> interface.
>
> anish: Mark moves Anish Seconds to resolve issue 56 by replacing
> paragraph at 1687-1689 in CAA CD01 spect with:
>
> anish: A component MUST NOT have two services with the same
> Java simple
> name. If a Java implementation needs to realize two services with the
> same Java s
>
> anish: imple name then this can be achieved through
> subclassing of the
> interface.
>
> Dave Booz: ping
>
> anish: motion approved w/o
>
> anish: Resolution: issue 56 is resolved with the above motion
>
> anish: Topic: Issue 3
>
> anish: JAVA-3 Local services expose implementation classes as
> their type No proposal but some discussion
> http://lists.oasis-open.org/archives/sca-j/200808/msg00098.html
>
> Mark Combellack: More discussions at:
> http://lists.oasis-open.org/archives/sca-j/200810/msg00039.html
>
> anish: Discussion on addition of @Local annotation.
>
> anish: @Local can be used in an interface, whereas @service
> has to be in
> the impl class
>
> Mark Combellack: Breaking until 11:20
>
> Mark Combellack: Resuming
>
> anish: Action: SimonN to raise 3 issues for each C&I wrt what
> happens if
> the annotation rules are not followed (SCA runtime MUST NOT
> deploy the
> component)
>
> anish: Simon moves Dave seconds to close issue 3 with no action
>
> anish: motion approved w/o
>
> anish: Resolution: Issue 3 is closed with no action
>
> anish: Topic: Issue 6
>
> anish: JAVA-6 @AllowsPassByReference requires more detailed
> description No proposal some suggestions in Jira
>
> anish: MikeE: two ways: a) get rid of the annotation, OR b) allow the
> same annotation for the reference (on the client side)
>
> anish: Action: MikeE to raise an issue in Assembly regarding
> @AllowPassByReference
>
> anish: Mark: do we have consensus on a direction for this
>
> anish: Action: Simon to provide proposal for issue 6
>
> anish: Topic: issue 28
>
> anish: Mary has come back and suggested org.oasisopen but has
> said that
> it is not necessary for OASIS to own this
>
> anish: General consensus that this does not make sense
>
> anish: Anish moves Simon seconds that using org.oasisopen
> without OASIS
> acquiring ownership of the domain does not make sense. And if
> OASIS is
> not willing to buy this domain we prefer to continue with the
> org.osoa
> package name
>
> anish: motion approved w/o
>
> anish: Action: Dave to draft email to raise an objection to TC admin
> decision
>
> anish: Lunch
>
> anish: resume @ 1:30pm
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS
> TC that generates this mail. Follow this link to all your
> TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
> oups.php
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]