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]

Reply via email to