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: Minutes of the f2f meeting (2007-09-19)



Title: SCA J F2F Minutes (2007-09-19)

SCA J F2F Minutes (2007-09-19)


Scribe: Anish Karmarkar


Agenda: http://lists.oasis-open.org/archives/sca-j/200709/msg00016.html

1. Agenda bashing

Agenda approved

2. Minutes of the previous minutes

Motion: Fred moves Dave seconds to approve the meeting minutes

no objection

3. Contributions








4. TC roles

4.1 Spec editors

Martin: do we want one team for all the specs or separate editors for different specs

MikeR: you don't have to volunteer for all the specs

MikeR: volunteers for any of the Java specs? we have 4 specfications right now

  1) common annotations & api

  2) implement.java

  3) implementation.spring

  4) Ejb session binding spec


Motion: Martin moves Peter seconds -- create a subcommittee for editors which will do all the spec work

no objection to the motion


There will be a single group for all the editors.


MikeR: would like to seek volunteer for this group

Volunteer: Ron, Peter Peshev, Ashok, Anish, Dave Booz


MikeR: any objections?

no objections to unanimous consent for accepting the volunteers as editors


Motion: Martin moves Jeff seconds to take the 4 contributions and apply an OASIS specification template and create the 1st working draft

no objection to unanimous consent


MikeR: any volunteers for being the secretary of this TC?

MikeR: another way is to keep a rotating scribe list

MikeR: we'll figure this out on a meeting-by-meeting basis

4.2 Issues process

Henning walks through the issues process slides from the Assembly TC


Motion: Jeff moves Sanjay seconds that --

To open an issue previously closed require a special majority vote as defined by OASIS rules and performed by web ballot but executed by chairs instead of TC admin

no objection to accepting the motion. motion passes

4.3 Issues editors

MikeR: any volunteers for issues editors?

Ron volunteers

no objections


Motion: Martin moves to 1) direct our issues editor to liaise with other SCA TC issues editors to ensure consistent issues process, and 2) follow the issues process outlined in powerpoint located at http://www.oasis-open.org/apps/org/workgroup/sca-j/email/archives/200709/msg00026.html

Dave Booz seconds

no objection. motion passes

5. Testing process and testing subgroup


topic postponed


6 Charter reivew


charter: http://www.oasis-open.org/committeees/sca-j/charter.php


Henning reviews the charter


Simon: why does the charter say 'recursive assembly in java ee applications' instead of just saying 'assembly in java ee ...'

MikeR: it is redundant but harmless

Simon: in that case I don't have an objection


DaveB: some of the bullets in the Java EE Scope need to be subbullets (session beans, MDB, JAX-WS annotated session beans


Owen: saying that anything not mentioned is out of scope is too limiting, for example what about apis for accessing security related info?

MikeR: 'annotations for policy intents' or 'Java API for accessing and manipulation of data ...' bullets are meant for that


Simon: Q on the deliverable section -- the test suite is not listed in the deliverable section

Jeff: it does not matter what is listed in the deliverable section, this is more to set the guidance and expectations

Simon: the deliverables section has a maintenance section and I would hope that the test suites are maintained as well

Martin: the deliverables section does not say that the test suite will be maintained but that is implied

Jeff: Simon, is your concern that the TC will not maintain the test suites?

Simon: having it in the deliverables section puts burden on the TC to maintain the test suites

MikeR: can't really force the TC to do anything

MikeE: i would be in favor of clarifying what should be done wrt maintenance of test suite. I opinion is that we should maintain it. Don't think we need to change the charter. May want to make a motion in the future

Martin: some slightly problematic wording ('... becoming an OASIS standard ...') but not a huge problem

MikeR: if there was a disagreement then it is worthwhile to get a charter clarification. This is not the case here, so would like to move past this

7. New issues

Simon: new issues -- with common annotation and api spec. Can have a proxy injected and then convert it to a callable reference, OR get a service ref from the request context info or the component context and then use the getService() api to get the proxy. The Q is: if I make a state change such as conversation id and I use the proxy, does the change show up immediately

Henning: that depends, have a similar open issue on relation of a service reference to conversaion

Simon: my scenario is different from that. It is an injected reference and then use the component context to convert injected ref to service ref

MikeR: the Q is: does the service ref share the proxy state

... I believe that they share state


... if it is not, then we should clarify that


Martin: are we discussing the issue or raise the issue?

MikeR: we have a process that says the issue has to be raised on email first

MikeR: since we are at a f2f, it is valuable to have a discussion now so that the issue could be written up correctly


Simon: this is about sharing state

... u can have a callback id without conversation

Jim: if we serialize that reference then do u have to propagate changes everywehre?

... do we update all the VMs?

MikeR: general agreement that this is a worthwhile issue to log

Simon: will write this up more formally


Simon: another issue --

... when i create a service ref (a brand new one), if I were to call getCallBackID() it would return null

MikeR: the spec does not say that, would be worthwhile to clarify

Simon: now if I use the service ref and make a call which has a callback and then call getCallback ID() then it would it still return null?

MikeR: should not return null at the next call

Simon: the spec does not say

... how much should the spec say

MikeE: i think that there are several place in the java spec and possibly in assembly spec where state is involved. State is not dealt with appropriately and this should be corrected. Such as a sequence diagram

MikeR: the two issues that simon raised are related. Do you think it is appropriate to make them a single issue

Simon: more suitable for two different issues

... i'll think about the linkage and see if it can be raised as a single issue


anish: suggestion that we put the issues template on the member home page


MikeE: i have an issue about a functionality that is currently missing. Will write it up. This is about the fact that there is metadata that can be applied to a component that cannot be applied to a java component

... example: i want a particular binding, the only way to do that is through the composite not possible as an annotation. Would like to allow such things to be specified using java annotations, which can be overridden

... the aim of this is to have a java component which is instantly deployable

martin: are we debating the solution or the issue itself

MikeE: may want to raise two issues instead of one

MikeE: 1st issue -- the meta Q is should it be possible to have a fully configured java component that requires no configuration to deploy

... this comes from the world of scripting

Anish: another way of looking at this is -- the componentType can specify the default binding. We don't require side files so we should think about specifying what is in the componentType in a java file

Jason: tools could generate the metadata

Jim: for a runtime you can have a default binding

MikeE: yes, but i may want a non-default

... binding

Jim: suppose a dev comes along and puts in an annotation with a URL, I would want to override it

Henning: how about having another issue about representing everything that is in the componentType in java


MikeR: there are some issues in OSOA Jira that we should look at

Henning: What APIs are available to unmanaged code?

... If the static method CurrentCompositeContext.getContext() is available to unmanaged code, which composites context is returned?

MikeE: there is a problem with this issue as stated. Don't know what unmanaged code means

Discussion on unmanaged code

MikeR: if SCA has not had any hand in create a class or there is not SCA configuration. For such a running class, there is no way to get to SCA-like things

MikeE: configuration is described in SCA starts at the domain

... anything that is describable in SCA has to be in a domain

... if a java bean that is sca unaware is deployed in the domain, how did that happen

MikeR: that is the question

MikeR: potentially could have a registry, there are other solutions

Anish: what is the motivation/use case for this

Jim: don't think there is a value for this

... one reason to do that is for someone who likes the sca abstraction and wants that functionality in code that is not sca-aware

mikeR: components offer external binding and anyone who wants to talk has to use the appropriate binding/url

... however people sometimes want to create a client somebody else figure out how to talk to that thing

peterP: this seems to belong to the assembly TC not java TC

peterP: this == this capability

MikeE: one way of looking at this -- here is some piece of code that is not sca-aware then there something that is needed at the runtime level make it part of the domain

martin: just raise the issue and then have discussion

MikeE: my problem was that 'unmanaged code' was not well defined

MikeE: the Q of having a JSP inside JavaEE, is that the same issue or a different issue

Henning: it is different

Henning: for this particular issue (unmanaged code), need to have more precise wordings


New Issue:


MikeR: spec allows passByRereference

... this is added for service provider to say that even if things are remotable it is ok to do pass by ref

... the spec is not correct in what is says should happen

... it says that the service will not modify the input param or return value even after returning from the operation

... problem with that: 1) if you don't make a copy, there are implications on teh client that it cann't muck with things till the call returns (for req-res) and for one-way it is more complicated, especially for multithreaded client

Simon: one solution might be an intent

MikeR: it is an intent, but it is on the class rather than the interface

Simon: that was what I was thinking


New issue:


henning: in wsdl2java we point to jax-ws

... in jax-ws there is a feature to generate asynch methods

... is that part of the spec Or does that need to specified OR should we say anything in SCA about it

MikeR: these async are for request-response from WSDL


New Issue:


MikeR: components that are deployed to the domain-level, after the component is deployed the target of the reference can change. EG a new wire element

... what do you do about injecting this new reference, especially for singleton components

MikeE: this is a problem for the runtime to solve. eg, through proxies

MikeR: one scenario is there is no target initial, it contains null. In that case one cannot intercept null.

Henning: there are cases where this is not a problem

... if the set of reference changes & you are not in the middle of an invocation then u dump the current deployed component and create a new instance. Especially true for non-long lived object

MikeE: stateful interactions clearly have a problem.

Anish: several cases -- can be autowired and references could be added

MikeE: one approach to this is to do something similar to OSGi and inform the components of changes programs then have to be aware of this

Anish: this can happen with properties as well, not just reference. Values of properties at the domain composite can change and a component may depend on it

DaveB: there is also a problem with promoted references and services


New issue:


Henning: how to have a thread safe operations over service ref


MikeR: this is about sequence of oeprations where you want to do something like set callback id etc and then make a call. The service reference is a shared obj in a multithreaded environment

... u can take the object injected on you and cast it to service ref. Multiple threads can do this. Each set callback ids.

... each operations are syched, which does not help

Simon: see two possibilities -- can do a copy (serialize and then deserialize) or do a java synchronized

... cloning seems bettern than synch

Jean-Sebastian: when i do a cast(), nothing says that it has to return the same reference

... i had assumed that it would be cloned in cast()

MikeR: I had assumed the opposite

Simon Nash: this is the shared state discussion again

Simon: can do a cast on the clone

... if we add the clone method

Simon Nash: actually it's a clone on the cast not a cast on the clone

Simon Nash: actually you are correct it would work the other way as well

Simon Nash: just realized that


Meeting Adjourned


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