Simon Laws wrote:
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)
So with this you just triggered a thought... and made me change my mind
about these methods. I was initially thinking - and going to argue about
:) - that we should just name these methods addComposite,
removeComposite. Now that I see it I like what you just proposed much
better, more explicit and clearer names, more in line with the spec.
+1 for addToDomainLevelComposite and addDeploymentComposite!
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
