Simon Laws wrote:
On 9/16/07, ant elder <[EMAIL PROTECTED]> wrote:
On 9/16/07, Simon Laws <[EMAIL PROTECTED]> wrote:
<snip>
A question though is should we flip the samples over to use NodeImpl
instead
of SCAdomain?
To save digging around in the code / ML, what is the new way exactly?
Currently things do:
org.apache.tuscany.sca.host.embedded.SCADomain.newInstance("
helloworldws.composite");
what is the new replacement approach?
...ant
org.apache.tuscany.sca.node.impl.NodeImpl node = new SCANodeImpl();
node.start();
node.getContributionManager().startContribution(The URL to your
contribution);
For example, for test purposes the URL could be:
SCANodeUtil.findContributionFromComposite(???.class.getClassLoader(),"
helloworldws.composite"));
So it's more lines but removes some of the mystery about where the
contributions are found.
Simon
I'm reviewing the API, and have a few comments:
* +1 to use the new API, with a few minor changes.
* The new API shouldn't expose implementation classes like NodeImpl or
cause the samples to have to a compile dependency on module node-impl.
I'd like to change "new NodeImpl()" to "SCANode.newInstance()".
* I'd prefer a convenient API to an inconvenient API forcing 90% of the
samples to use an SCANodeUtil side class to give that API what it wants.
I'd suggest to move findContributionFromComposite() to SCANode and not
expose an SCANodeUtil which will quickly become a mixed bag of things.
* Cosmetic, getUri should be changed to getURI to be consistent with the
osoa.sca API. I can take care of this minor change :)
I'm going to try to use the API in some of the samples and will try to
come up with more comments soon today.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]