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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
