[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: SCA-J minutes 6 Dec 2007
Michael Rowley: US & Canada Toll Free: (866) 484-4232 International Dial-In Number: (702) 894-2358 ACCESS CODE: 960335 Chat room: http://webconf.soaphub.org/conf/room/sca-j-TC Agenda 1. Preliminaries - 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 previous meeting(s) http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/26269/SCA%20Java%20Minutes%202007-11-29 2. Accepting new issues: None submitted. 3 . Issues discussion Issue #4: Dependency Reinjection Continuing from the 2007-11-08 meeting and the 2007-11-29 meeting, where we decided: - The editors should be directed to add wording to the specification: Dependency injection for callbacks cannot be used for composite scoped components. - The setcallback method can not be called while a conversation is in progress. The spec should say that @Callbacks will never be reinjected. This week: reference reinjection as described in the issue: http://www.osoa.org/jira/browse/JAVA-4 Please review mail thread startin from Michael Rowley's proposal:http://www.oasis-open.org/apps/org/workgroup/sca-j/email/archives/200711/msg00029.html Issue #3 - Local services expose implementation classes as their type see mail thread: http://lists.oasis-open.org/archives/sca-j/200710/msg00059.html Issue #8: Concurrency model for Service Reference instances http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/25725/sca-j-issue_8_proposal.ppt 4. Adjourn --------------------------------------------------------------- Rotating scribe list: Martin Chapman Oracle Corporation Jason Kinner Oracle Corporation Jeff Mischkinsky Oracle Corporation Peter Peshev SAP AG Roberto Chinnici Sun Microsystems Peter Walker Sun Microsystems Sriram Narasimhan TIBCO Software Inc. Pradeep Simha TIBCO Software Inc. Scott Vorthmann TIBCO Software Inc. Bryan Aupperle IBM Michael Keith Oracle Corporation Uday Joshi Oracle Corporation ---- scribed once ----- Anish Karmarkar Oracle Corporation Mike Edwards IBM Michael Beisiegel IBM Ashok Malhotra Oracle Corporation David Booz IBM Simon Nash IBM Jim Marino BEA Systems, Inc. Ron Barack SAP AG Sanjay Patil SAP AG anish michael i just joined anish pl. put me on the roll, when u get a chance Dave Booz and we need a scribe Jason Kinner: Scribe: Jason Kinner henning: Ron is here now! Jason Kinner: M: Walker, S: Beisiegel to accept minutes from last meeting accepted w/o Jason Kinner: Nash: Combined meeting with Bindings during w/c 3 March; preference for Tue-Fri; bindings prefers Tue-Wed Jason Kinner: Karmarkar: Suggests we alternate first picks Jason Kinner: Nash to deliver recommendation for Tue-Wed for Bindings, Thu-Fri for Java at F2F Mike Edwards: I joined too ! Jason Kinner: Roll: 9/17 53% quorate Jason Kinner: Discussion about Issue #4 Jason Kinner: Booz: We eliminated constructor reinjection because it isn't possible in Java. Depending on a current behavior of Java. Relying on this as the sole mechanism to indicate lack of support for reinjection may not hold if Java changes. Would prefer an explicit indicator. Jason Kinner: Rowley: Should be possible to rewire target of some of the references without requiring restart of, say, a process Jason Kinner: Edwards: Seems reasonable to use constructor injection to disallow reinjection, since Java doesn't support reinjection in this way henning: Jim: this does not count as majortiy!! Jason Kinner: [henning] ??? henning: (just kidding about raising your hand 3 times under different names) Jason Kinner: Rowley: Applicable to "conversational" scope components? Jason Kinner: Conversational component wired to non-conversational interface, in what way is it an issue to be rewired? Jason Kinner: Blohm: Non-conversational component may still be "stateful" in that it could have information in DB, etc., and conversational component may rely on that state Jason Kinner: Peshev: Consider a case where a conversational component invokes the non-conversational component multiple times over a longer period of time. The wiring changes between these invocation. Jason Kinner: Marino: Isn't it the job of the runtime to migrate state if necessary? Jason Kinner: Marino: Or, if the state cannot be migrated, wouldn't it be an error to rewire it? Jason Kinner: M: Blohm, S: Nash reinjection should NOT be applicable to conversation components Jason Kinner: s/conversation/conversational/ Mike Edwards: If I dont allow reinjection then how did the component get the update Mike Edwards: in which case the component involved lives with the old interfacde Jason Kinner: Blohm: Perhaps this should be the behavior if reinjection is not supported? You can always get the latest by querying. Jason Kinner: Booz: Issue is with the reference, not the target component. Jason Kinner: Peshev: References should at least be invalidated on a change Jason Kinner: Nash: If the conversational component holding the reference to the previous target, then any subsequent attempt should throw an error Jason Kinner: Blohm: If the target changes, then references to the target should be invalid Jason Kinner: Nash: A->B, then A->C, but instance of A still refers to B; could I still get B? An error? anish requests a private chat with you Mike Edwards: this raises all the meta-issues about the behaviour of the domain Jason Kinner: Rowley: For "stateless" or "request", the instance doesn't live long enough to matter; "composite" lives longer, so it matters, "conversational" matters. Jason Kinner: Nash: Transparently redirecting to C might matter Jason Kinner: Blohm: If the rewiring directs you to new state, it could matter henning: very good example!! Mike Edwards: I was trying to point out that this discussion impinges on how the evolution of the domain is described Mike Edwards: if the component can carry on using the "old wiring", then in effect you have multiple versions of the domain config in existence at the same time Jason Kinner: Rowley: What if the composite relies on BPEL (business data in the message) for correlation. From SCA, the component is stateless, but it isn't, truly. Jason Kinner: [Mike: I agree, and I was trying to point out earlier that it could be desirable to have that behavior] Jason Kinner: Booz: What if the new component is actually interchangeable with the previous target? Jason Kinner: Rowley: Interface isn't enough to determine if the components are interchangeable Mike Edwards: it would be wise to examine that design further before we try to make a decision on this less important point anish michaelR, I have to go can u get me on the role please anish unfortunately, can't stay for straggler roll anish s/role/roll/ Michael Rowley will do Jason Kinner: Kinner: Are we really just describing an optimization that isn't strictly required? Jason Kinner: Rowley: Call for vote on the motion Jason Kinner: M: Blohm, S: Nash reinjection should NOT be applicable to conversation components Jason Kinner: s/conversation/conversational/ Jason Kinner: Motion passed: 8 for, 2 against, 5 abstain Michael Rowley: Current proposal Michael Rowley: Reinjection ----------- References MAY be reinjected after the initial creation of a component due to a change in wiring that has occurred since the component was initialized. In order for reinjection to occur, the following MUST be true: - The component MUST be composite-scoped. - The reference MUST use either field-based injection or setter injection. References that are injected through constructor injection MUST NOT be changed. - If the reference has a conversational interface, then a conversation MUST NOT be active at the time of the reinjection. If processing in reaction to a change in a reference is necessary, then setter injection should be used, with code in the setter method that does the proper processing in reaction to a change. Components with any scope other than the composite scope MUST NOT have references reinjected. If an operation is called on a reference where the target of that reference is no longer valid, then InvalidServiceException MUST be thrown. In cases where changes to a reference are not valid, the reference as accessed through the component context also MUST NOT change. More precisely, the ComponentContext.getService() and getServiceReference() methods MUST return the same reference target as would be accessed through injection. However, the ServiceReference that is returned by getServiceReference() never changes its target. If the wiring of a composite component causes a reference to be reinjected, any ServiceReference object that was acquired before the reinjection will still correspond to the target prior to the change. If the target service for a ServiceReference ever becomes invalid, then attempts to call business methods through that ServiceReference MUST throw InvalidServiceException. The rules for reference reinjection also apply to references with a 0..N or 1..N. This means that in the cases listed above where reference reinjection is not allowed, the array or Collection for the reference MUST NOT change their contents. In cases where the contents of a reference collection MAY change, then for references that use setter injection, the setter method MUST be called for any change to the contents. The injected collection MAY be the same collection object as is currently used by the component, but with some change to its contents. Jason Kinner: Rowley: AI for all: Check the complete proposal and identify issues to be addressed for acceptance Jason Kinner: Rowley: Will be meeting next week Jason Kinner: Meeting adjourned
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]