[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes of the f2f meeting (2007-09-19)
Attached. -Anish --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 bashingAgenda approved 2. Minutes of the previous minutesMotion: Fred moves Dave seconds to approve the meeting minutes no objection 3. Contributions 4. TC roles4.1 Spec editorsMartin: 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 processHenning 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 editorsMikeR: any volunteers for issues editors? Ron volunteersno 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 issuesSimon: 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 codeMikeR: 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]