[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: ISSUE 41: Conflicting domain-level <wire> deployments
Peter, I admit that I was somewhat uncomfortable about my original proposal that later wire deployments override older conflicting wire deployments. Your comment that the older deployment should instead be updated instead is a good one. However, I would not do it by keying on the name of the composite. I would instead require that the original contribution be updated, possibly by a call to the logical "updateDeploymentComposite" function. Do you like that approach? Michael -----Original Message----- From: Peshev, Peter [mailto:peter.peshev@sap.com] Sent: Wednesday, January 23, 2008 5:29 AM To: Michael Rowley; OASIS Assembly Subject: RE: ISSUE 41: Conflicting domain-level <wire> deployments Hi Michael, A couple of thoughts about the issue : At least my interpretation is that the composite name in sca-contribution should be a key to the runtime. The runtime could and should determine by this key whether this contribution is a brand new or an update of existing version. I.e. suppose component1/ref1 has multiplicity 0..n , when I deploy -- <composite name="WiringComposite" <wire source="component1/ref1" target="component2/ref2"/> </composite> that should add new <wire> as a target for the reference, however when I deploy much later another contribution : <composite name="WiringComposite" <wire source="component1/ref1" target="component3/ref3"/> </composite> that should NOT add but instead replace, since I have supplied newer version of WiringComposite. How and when *replace* is done should be according to spcific implementations (java issue-4 for example). If I wanted to add a new wire that should be added, I could supply <composite name="New_Name_Without_Conflict" <wire source="component1/ref1" target="component3/ref3"/> </composite> The question of how such wires are removed -- well, I would assume that there are two options -- I would assume that each runtime would offer some mechanism of undeployment, either via a management interface or via some proprietary tooling. Section 10.4 hints on that. So that can be used as well to remove the wire supplied as contribution. -- somewhat artificial, but the assembler could provide a new version of the wire contribution, where the target is empty. I.e. by deploying : <composite name="New_Name_Without_Conflict" <wire source="component1/ref1" target=""/> </composite> About "Later wire deployments should override existing wire" deployments for 0..1 or 1..1 references. ": If the initial wiring was supplied via a dedicated contribution with a wire in it, than the mechanism above used for supplying new versions as a contribution using the unique name can be used to change the target. The question arises as to what to do in case the initial wiring was supplied via <reference target="...", > and someone deploys a contribution with wire, or there is already existing wire, and someone deploys a new contribution (not an update to the existing one). Just for simplicity that could be classified as an error. An update of an existing configured contribution should not be done by deployment from outside as another one but from a management model that a vendor could expose. Btw, sorry if some of those were already discussed and rejected on the F2F, it was hard for me to follow all the talks and it was pass midnight here :). Best Regards Peter -----Original Message----- From: Scott Vorthmann [mailto:scottv@tibco.com] Sent: Wednesday, 23. January 2008 02:56 To: Michael Rowley Cc: OASIS Assembly Subject: [LIKELY JUNK][sca-assembly] ISSUE 41: Conflicting domain-level <wire> deployments http://www.osoa.org/jira/browse/ASSEMBLY-41 On Jan 22, 2008, at 4:43 PM, Michael Rowley wrote: > > RAISER: Michael Rowley > > TARGET: SCA Assembly Specification WD 2, section 6.4 Wire > > DESCRIPTION: > > If a component is deployed with a wire target, and then a later > deployment includes a <wire> for the same component reference, what > should happen? > > Is the answer different if the multiplicity is 0..1, 1..1 or 0..n? > If we treat 0..n so that new <wire> add targets for the reference, > is there any way to remove targets? > > What should happen for later conflicting <wire> deployments? > > PROPOSAL: > > (informally) Later wire deployments should override existing wire > deployments for 0..1 or 1..1 references. For 0..n references, new > <wire target=""> elements are additive. We should introduce a new > attribute <wire all_targets=""> which replaces the complete list of > targets for the @source. > --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]