Some clarification below.
Simon
On 10/9/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> Comments inline.
>
> Simon Laws wrote:
> > On 10/9/07, ant elder <[EMAIL PROTECTED]> wrote:
> >
> >> On 10/8/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> >> <snip>
> >>
> >>
> >>>> Does the spec say anywhere that when there is no
> >>>>
> >> sca-contribution.xmlthen
> >>
> >>>> composites in a contribution must not be added by default?
> >>>>
> >>>>
> >>> Assembly specification V1.0
> >>>
> >>> 2867 The contribution optionally contains a document that declares
> >>> runnable composites, exported
> >>> 2868 definitions and imported definitions.
> >>> ...
> >>> 2887 deployable element: Identifies a composite which is a composite
> >>> within the contribution that is
> >>> 2888 a composite intended for potential inclusion into the virtual
> >>> domain-level composite. Other
> >>> 2889 composites in the contribution are not intended for inclusion but
> >>> only for use by other
> >>> 2890 composites. New composites can be created for a contribution
> after
> >>> it is installed, by using the
> >>> 2891 add Deployment Composite capability and the add To Domain Level
> >>> Composite capability.
> >>>
> >>> This tells me that:
> >>>
> >>> - sca-contribution.xml is optional
> >>> - composites not listed as deployables are not intended for inclusion
> >>> - composites can be included in the domain after contribution,
> manually
> >>> using the addDeploymentComposite and addToDomainLevel operations
> >>> - the spec says "potential inclusion" and does not even imply that
> >>> deployable composites should be included in the domain by default
> >>>
> >> But thats all about when the IS an sca-contribution.xml not what
> happens
> >> when there is NOT one.
> >>
> >> Including all composites in the domain by default when there's no
> >>
> >>> sca-contribution.xml is going to be pretty inconvenient and confusing
> as
> >>> it'll force people to ship an empty sca-contribution.xml file in all
> >>> contributions containing only composites intended for use by other
> >>> composites (aka implementations).
> >>>
> >> How common will that be? If you look at all the dozens and dozens of
> >> composites we have in the Tuscany tests and samples the vast majority
> >> (all?) of them are intended to get deployed. Maybe those are 'simple'
> cases but
> >> aren't those the cases we should try to keep the API as simple as
> possible
> >> for?
> >>
>
> As soon as you have real applications with nested composition, i.e.
> using <implementation.composite> then you don't want all composites to
> be added by default.
> As soon as you have <include> as well, adding the included composites to
> the domain by default will cause errors.
> Both cases will cause errors (name collisions, incorrect configuration
> of nested composites), which may prevent the contribution to even be
> deployed.
>
> >> Along with the add methods if there's also remove methods then
> composites
> >> could still be removed so in those less common simple cases where
> having
> >> things added by default is inconvenient then you can simply remove
> them.
> >>
> >> ...ant
> >>
> >>
>
> So if I understand correctly, we would add too much to the domain by
> default, work around the errors caused by doing so (as I tried to
> explain above) and then ask the application developer to write code to
> remove what we've added... Are you really serious?
>
> >
> > Can't we go with the approach that says that;
> >
> > 1/ If there is sca-contribution.xml style meta-data it is honored and
> > referenced composites are deployed
> > 2/ If there is no sca-contribution.xml style meta data then you are
> required
> > to explicitly add composites to the domain through the API
> >
> > There is no magic, i.e. if sca-contribution.xml/generated-
> > sca-contribution.xml/deplyables doesn't exist it doesn't go looking
> > elsewhere for contributions. Most of our SCA applications to date fall
> into
> > category 1/ I believe
>
> +1 that makes more sense to me.
>
> I'd add to (1) what we discussed before on this list: Placing your
> .composite file under META-INF/sca-deployables is equivalent to
> declaring it in sca-contribution.xml. This is a convenient shortcut for
> people allergic to angle brackets who don't want to write an
> sca-contribution.xml file.
+1
> and hence we could do away with the need to
> > startContribution(QName) on a node leaving.
> >
>
> +1 for doing away with startContribution(QName), I didn't think we
> actually had such a method :) and I'm not sure that starting/stopping
> contribution really fits the model. IMO contributions are
> installed/uninstalled, composites are added / removed to/from the
> domain, composites (and the components in the composites) are
> started/stopped.
> Using a node in its own
> > nodeA = SCANodeFactory.newInstance().createSCANode("nodeA",
> > null);
> > nodeA.addContribution("nodeA", cl.getResource("nodeA/"));
> > nodeA.start(); or for composite level control
> > nodeA.startComposite(new QName("http://sample";, "Calculator"));
> > Or using the domain
> > domain = SCADomainFactory.newInstance
> > ().createSCADomain(DEFAULT_DOMAIN_URI);
> > nodeA = SCANodeFactory.newInstance().createSCANode("nodeA",
> > DEFAULT_DOMAIN_URI);
> > domain.addContribution("nodeA", cl.getResource("nodeA/");
> > domain.start(); or for composite level control
> > domain.startComposite(new QName("http://sample";, "Calculator"));
> >
> >
> > I'm not clear why the the spec says "potential inclusion" on line 2888.
> > Possibly to do with a contribution that is a dependent contribution. But
> for
> > the purpose of explicit contributions, deployable composites should be
> > deployed as specified in the meta-data if it is provided.
> >
> >
> > I think we need to rename our current Domain API methods
> >
> > addComposite()
> > removeComposite()
> >
> > to become
> >
> > addCompositeToDomain(QName)
> > removeCompositeFromDomain(QName)
> >
> > This message needs to be targeted at the node(s) which have the
> > contribution/composite. This leaves the way clear then for the missing
> > methods
> >
> > addComposite(Composite XML)
> > removeComposite(Composite XML)
> >
>
> I'm not sure about what you have in mind here. Are you trying to have
> different method names to avoid method overloading? or are there really
> different semantics behind addCompositeToDomain(QName) and
> addComposite(XML)?
Yes, sorry for the confusion, you are correct the latter should have been
addDeploymentComposite. And, looking at the spec, the addCompositeToDomain
is presented as addToDomainLevelComposite. So we would have.
addToDomainLevelComposite(CompositeQName)
addDeploymentComposite(ContributionURI, CompositeXML)
> Which allows a composite to be added rather than just be deployed.
> >
>
> I'm probably mis-understanding what you have in mind... Are you
> referring to the ability to add deployment composites by value described
> in the spec? What difference do you see between add (to the domain?) and
> deploy?
>
>
> >
> > We would also need to modify the Node API to allow for these rules and
> allow
> > the node to report back to the domain which composites it's taking care
> of
> > in the case where they are deployed based on meta data.
> >
> >
> > Regards
> >
> > Simon
> >
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
