Comments inline.
Luciano Resende wrote:
Hi
Currently, the SCADomain uses the following signature for newInstance :
public static SCADomain newInstance(String domainURI, String
contributionLocation, String...composites)
And sample applications are using like :
SCADomain domain = SCADomain.newInstance("http://calc";, ".", "
Calculator.composite");
Most samples are not even doing that, they're using the simpler form:
SCADomain domain = SCADomain.newInstance("Sample.composite");
basically the equivalent of the former:
SCARuntime.start("Sample.composite");
I have a quick question :
- Why we would need to specify multiple composites from one same
contribution ?
Having multiple composites from a contribution as deployables is allowed
by the spec. I don't think we can have a limitation one-contribution /
one-deployable.
Currently we have the getDeployables from a contribution that
would give you all deployable composites based on contribution
metadata side
file ( sca-contribution.xml)
Right, you can specify the deployables in sca-contribution.xml, but the
current SCADomain API provides a simpler Java based alternative for
clients and saves you from having to write that file or using an
administration tool to add deployable composites. You are actually
proposing a variation of this API later in this email so I'm assuming
that you find it useful :)
or in the case that file is not available, it
would promote all composites to be deployable.
Adding all composites in a contribution to the domain automatically is a
recipe for trouble. This will basically force you to write an empty
sca-contribution.xml in all contributions that contribution artifacts
that you want to reuse across applications, to prevent them to be added
automatically to the domain as top-level composites. Also most of the
times if you have multiple composites in a contribution, chances are
that one will include or use another as an implementation, causing a
collision error in the include case, and going against the original
intent in the second case.
Can that be used instead ? If
so, do we need to pass the deployable composites at al ?
No we should be able to create an SCADomain without passing composites.
If no composites are passed then you must have an sca-contribution.xml
file in your contribution. This file will serve two purposes:
(a) indicate the actual location of the contribution (we currently use
the composite file to determine that location)
(b) declare the deployables.
We'll just need to make a small change to SCADomain to implement (a).
Also, I'd suggest to have something more towards the code below :
SCADomain.newInstance(domainURI);
SCADomain.addContribution(uri, location);
SCADomain.addComposite(composite);
This would probably also be more aligned to the spec...
Thoughts ?
This is starting to look like an SCA domain administration API (a mix of
the current ContributionService and a DomainService). You'll need
methods like add/remove/find contribution, add/remove/find deployable
composite, getDomainComposite() etc, going beyond the needs of a simple
client that wants to bootstrap a runtime. The current
o.a.t.host.embedded.SCADomain is a simple bootstrapping class meant to
replace the SCARuntime.start(composite) that we had before, it is not
meant to be a full blown administration API. What you are proposing is
nice, but for different use cases, so I would suggest to have this
separate from the small and simple o.a.t.host.embedded.SCADomain.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
