Using Node/Domain API, was: SCA 1.0 RC1 artifacts available for review

[Jean-Sebastien Delfino <js...@gmail.com>]

Simon Laws wrote:
> On 9/16/07, ant elder <an...@apache.org> wrote:
>   
>> On 9/16/07, Simon Laws <si...@googlemail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Using Node/Domain API, was: SCA 1.0 RC1 artifacts available for review

[Jean-Sebastien Delfino <js...@apache.org>]

Jean-Sebastien Delfino wrote:
> Simon Laws wrote:
>> On 9/16/07, ant elder <an...@apache.org> wrote:
>>  
>>> On 9/16/07, Simon Laws <si...@googlemail.com> 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
>

I tried the API and would like to propose something simpler, and closer 
to the SCADomain API currently used everywhere in samples and tests.

I committed it there so that people can take a look:
http://svn.apache.org/repos/asf/incubator/tuscany/branches/sca-java-1.0/modules/node-api/src/main/java/org/apache/tuscany/sca/node/smaller

I'd like to do the following:
- keep the samples and test cases that use oat.host.embedded.SCADomain 
unchanged, as it's really too late to change them now, if RC2 is going 
to be cut tomorrow
- use the node API, in it's simpler/smaller form in the 
calculator-distributed sample
- move the rest out of node-api as it's dragging dependencies on SPIs 
and the core runtime, and I think we should keep the strict minimum in 
an API module.

Thoughts?

-- 
Jean-Sebastien


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org