You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Raymond Feng <en...@gmail.com> on 2007/05/08 02:21:48 UTC

Brief guide for extending Tuscany

Hi,

I uploaded a brief guide for extending Tuscany to the following wiki page. 
Please review and help improve it.

http://cwiki.apache.org/confluence/download/attachments/51879/ExtendingTuscany.ppt

Thanks,
Raymond 


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


Re: Brief guide for extending Tuscany

Posted by Jean-Sebastien Delfino <js...@apache.org>.
[snip]
Jean-Sebastien Delfino wrote:
> Jean-Sebastien Delfino wrote:
>> ant elder wrote:
>>> I wondered if we should get rid of ProviderActivator and just have
>>> ServiceBindingProvider, ReferenceBindingProvider and 
>>> ImplementationProvider
>>> explicitly define the start/stop methods.
>>
>> +1, good idea.
>>
>>>

Just commited that change under revision r536360.

-- 
Jean-Sebastien


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


Re: Brief guide for extending Tuscany

Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jean-Sebastien Delfino wrote:
> ant elder wrote:
>> I wondered if we should get rid of ProviderActivator and just have
>> ServiceBindingProvider, ReferenceBindingProvider and 
>> ImplementationProvider
>> explicitly define the start/stop methods.
>
> +1, good idea.
>
>>
>> Also, I'm wondering if having BindingProviderFactory extend Binding and
>> ImplementationProviderFactory extend Implementation is just a way to 
>> try to
>> reuse the existing module extension framework, and that doing this is 
>> ending
>> up making things a bit less clear than they could be? Would it 
>> cleaner and
>> clearer to have separate BindingActivator and ImplementationActivator
>> interfaces which include the methods from the XxxProfiderFactory 
>> interfaces
>> and have separate discovery for these which the runtime uses 
>> explicitly. I
>> think (need to prototype it to see) this would make binding and
>> implementation extensions much simpler, and it would make the core 
>> runtime a
>> bit cleaner as well by removing all the if instanceof and casting.
>>
>>   ...ant
>>
>
> Yes, good point, it will be clearer.
>
> I'll try to refactor this just a bit more :) and will disconnect the 
> ProviderFactory from the underlying model. The ProviderFactory for a 
> given model will then be registered with the Model class in a way 
> similar to what we do with ArtifactProcessors.
>

It took me a little longer than expected as I'm at JavaOne today and 
couldn't get a steady wireless connection for more than 20 seconds, so I 
had to do small commits :) but these changes are in now. The providers 
do not extend anymore the model, they are separate, created by 
ProviderFactories registered in a ProviderFactoryExtensionPoint 
extension point. I ported all our binding and implementation extensions, 
including the samples, but excluding the WebService binding extension.

-- 
Jean-Sebastien


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


Re: Brief guide for extending Tuscany

Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> I wondered if we should get rid of ProviderActivator and just have
> ServiceBindingProvider, ReferenceBindingProvider and 
> ImplementationProvider
> explicitly define the start/stop methods.

+1, good idea.

>
> Also, I'm wondering if having BindingProviderFactory extend Binding and
> ImplementationProviderFactory extend Implementation is just a way to 
> try to
> reuse the existing module extension framework, and that doing this is 
> ending
> up making things a bit less clear than they could be? Would it cleaner 
> and
> clearer to have separate BindingActivator and ImplementationActivator
> interfaces which include the methods from the XxxProfiderFactory 
> interfaces
> and have separate discovery for these which the runtime uses 
> explicitly. I
> think (need to prototype it to see) this would make binding and
> implementation extensions much simpler, and it would make the core 
> runtime a
> bit cleaner as well by removing all the if instanceof and casting.
>
>   ...ant
>

Yes, good point, it will be clearer.

I'll try to refactor this just a bit more :) and will disconnect the 
ProviderFactory from the underlying model. The ProviderFactory for a 
given model will then be registered with the Model class in a way 
similar to what we do with ArtifactProcessors.

-- 
Jean-Sebastien


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


Re: Brief guide for extending Tuscany

Posted by ant elder <an...@gmail.com>.
I wondered if we should get rid of ProviderActivator and just have
ServiceBindingProvider, ReferenceBindingProvider and ImplementationProvider
explicitly define the start/stop methods.

Also, I'm wondering if having BindingProviderFactory extend Binding and
ImplementationProviderFactory extend Implementation is just a way to try to
reuse the existing module extension framework, and that doing this is ending
up making things a bit less clear than they could be? Would it cleaner and
clearer to have separate BindingActivator and ImplementationActivator
interfaces which include the methods from the XxxProfiderFactory interfaces
and have separate discovery for these which the runtime uses explicitly. I
think (need to prototype it to see) this would make binding and
implementation extensions much simpler, and it would make the core runtime a
bit cleaner as well by removing all the if instanceof and casting.

   ...ant

On 5/8/07, Ignacio Silva-Lepe <is...@gmail.com> wrote:
>
> This guide seems to be obsolete already, as we now seem to have a single
> ProviderActivator interface extended by the BindingProvider interfaces.
> Also, there is now a BindingProviderFactory interface that is not shown.
> How
> is this last one intended to be used? The RMI binding shows it as
> implemented by RMIBindingProviderFactory, which extends RMIBindingImpl
> (!),
> but it's not clear how else a binding factory should be used otherwise.
>
>
> On 5/7/07, Raymond Feng <en...@gmail.com> wrote:
> >
> > Hi,
> >
> > I uploaded a brief guide for extending Tuscany to the following wiki
> page.
> > Please review and help improve it.
> >
> >
> >
> http://cwiki.apache.org/confluence/download/attachments/51879/ExtendingTuscany.ppt
> >
> > Thanks,
> > Raymond
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>

Re: Brief guide for extending Tuscany

Posted by Ignacio Silva-Lepe <is...@gmail.com>.
This guide seems to be obsolete already, as we now seem to have a single
ProviderActivator interface extended by the BindingProvider interfaces.
Also, there is now a BindingProviderFactory interface that is not shown. How
is this last one intended to be used? The RMI binding shows it as
implemented by RMIBindingProviderFactory, which extends RMIBindingImpl (!),
but it's not clear how else a binding factory should be used otherwise.


On 5/7/07, Raymond Feng <en...@gmail.com> wrote:
>
> Hi,
>
> I uploaded a brief guide for extending Tuscany to the following wiki page.
> Please review and help improve it.
>
>
> http://cwiki.apache.org/confluence/download/attachments/51879/ExtendingTuscany.ppt
>
> Thanks,
> Raymond
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>

Re: Brief guide for extending Tuscany

Posted by Rashmi Hunt <ra...@gmail.com>.
Raymond,

I didn't see a section on "How to add a data binding type?", although it's
in the list of contents.
Will this be added as well?

Thanks
Rashmi

On 5/11/07, Raymond Feng <en...@gmail.com> wrote:
>
> We'll update it.
>
> Thanks,
> Raymond
>
> ----- Original Message -----
> From: "Matthew Sykes" <sy...@gmail.com>
> To: <tu...@ws.apache.org>
> Sent: Friday, May 11, 2007 5:22 AM
> Subject: Re: Brief guide for extending Tuscany
>
>
> > Raymond,
> >
> > Will this be updated when the 0.90 branch is out?  I was going to take a
> > look at it but deferred after reading Ignacio's comment that "This guide
> > seems to be obsolete already."
> >
> > Thanks.
> >
> > Raymond Feng wrote:
> >> Hi,
> >>
> >> I uploaded a brief guide for extending Tuscany to the following wiki
> >> page. Please review and help improve it.
> >>
> >>
> http://cwiki.apache.org/confluence/download/attachments/51879/ExtendingTuscany.ppt
> >> Thanks,
> >> Raymond
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
> >
> > --
> > Matthew Sykes
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>

Re: Brief guide for extending Tuscany

Posted by Raymond Feng <en...@gmail.com>.
We'll update it.

Thanks,
Raymond

----- Original Message ----- 
From: "Matthew Sykes" <sy...@gmail.com>
To: <tu...@ws.apache.org>
Sent: Friday, May 11, 2007 5:22 AM
Subject: Re: Brief guide for extending Tuscany


> Raymond,
>
> Will this be updated when the 0.90 branch is out?  I was going to take a 
> look at it but deferred after reading Ignacio's comment that "This guide 
> seems to be obsolete already."
>
> Thanks.
>
> Raymond Feng wrote:
>> Hi,
>>
>> I uploaded a brief guide for extending Tuscany to the following wiki 
>> page. Please review and help improve it.
>>
>> http://cwiki.apache.org/confluence/download/attachments/51879/ExtendingTuscany.ppt 
>> Thanks,
>> Raymond
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
> -- 
> Matthew Sykes
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> 


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


Re: Brief guide for extending Tuscany

Posted by Matthew Sykes <sy...@gmail.com>.
Raymond,

Will this be updated when the 0.90 branch is out?  I was going to take a 
look at it but deferred after reading Ignacio's comment that "This guide 
seems to be obsolete already."

Thanks.

Raymond Feng wrote:
> Hi,
> 
> I uploaded a brief guide for extending Tuscany to the following wiki 
> page. Please review and help improve it.
> 
> http://cwiki.apache.org/confluence/download/attachments/51879/ExtendingTuscany.ppt 
> 
> 
> Thanks,
> Raymond
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> 
> 

-- 
Matthew Sykes

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