You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by ant elder <an...@gmail.com> on 2007/05/31 15:59:20 UTC
Even simpler SPI for binding and implementation extensions?
I was trying to update the extension writers guide on the wiki and found it
really hard to say simply and clearly what (and why) each step is needed.
Now that there's quite a few extensions written to look at to see how things
are being done I think we could simplify the SPI for these a bit moreby
having something like a new discoverable activator like this:
public interface BindingActivator<B extends Binding> {
Class<B> getModelType();
StAXArtifactProcessor<B> getSCDLProcessor();
ReferenceBindingProvider createReferenceBindingProvider(RuntimeComponent
rc, RuntimeComponentReference rcr, B b);
ServiceBindingProvider createServiceBindingProvider(RuntimeComponent rc,
RuntimeComponentService rcs, B b);
}
And then (borrowing an earlier idea from Sebastien) BindingActivator impls
can use constructor args for any required extensions they need (eg
ServletHost) and the runtime automatically sets them without the impl
needing to explicitly locate them itself from the registry.
This would make the extension code a lot simpler and more obvious and clear
exactly what must be implemented, and it removes the dependency on the
ExtensionPointRegistry.
All the old SPI continues to work, they would be like an advanced or system
SPI, but simpler binding and implementation extensions could use this more
simple interface.
Any objections if I go ahead and try this?
...ant
Re: Even simpler SPI for binding and implementation extensions?
Posted by ant elder <an...@gmail.com>.
On 5/31/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> ant elder wrote:
> > I was trying to update the extension writers guide on the wiki and
> > found it
> > really hard to say simply and clearly what (and why) each step is
> needed.
> > Now that there's quite a few extensions written to look at to see how
> > things
> > are being done I think we could simplify the SPI for these a bit moreby
> > having something like a new discoverable activator like this:
> >
> > public interface BindingActivator<B extends Binding> {
> > Class<B> getModelType();
> > StAXArtifactProcessor<B> getSCDLProcessor();
> > ReferenceBindingProvider
> > createReferenceBindingProvider(RuntimeComponent
> > rc, RuntimeComponentReference rcr, B b);
> > ServiceBindingProvider
> > createServiceBindingProvider(RuntimeComponent rc,
> > RuntimeComponentService rcs, B b);
> > }
> >
> > And then (borrowing an earlier idea from Sebastien) BindingActivator
> > impls
> > can use constructor args for any required extensions they need (eg
> > ServletHost) and the runtime automatically sets them without the impl
> > needing to explicitly locate them itself from the registry.
> >
> > This would make the extension code a lot simpler and more obvious and
> > clear
> > exactly what must be implemented, and it removes the dependency on the
> > ExtensionPointRegistry.
> >
> > All the old SPI continues to work, they would be like an advanced or
> > system
> > SPI, but simpler binding and implementation extensions could use this
> > more
> > simple interface.
> >
> > Any objections if I go ahead and try this?
> >
> > ...ant
> >
>
> +1, I think we could even go a little bit further and provide a
> simplification layer...
> - covering component implementation types as well as bindings
> - saving the extension developer from having to write an XML artifact
> processor, for simple cases we could introspect the binding model and
> simply map its fields to simple XML attributes.
> - hiding the ProviderFactory and Provider layers
>
> Ideally, for simple cases, I'd just want to write:
> - a Binding or Implementation type model class
> - an Invoker to handle invocations on SCA references
> - a Listener to handle start/stop and incoming SCA service invocations
> - a single Activator class tying the above together.
>
> This layer would not alter or replace the current SPI, it would just be
> a simplification convenience layer on top of the current pluggability
> story, covering simple binding and implementation type cases. I'd
> suggest to put this layer in different packages.
>
> Thoughts?
All sounds really good to me, i like it a lot.
...ant
Re: Even simpler SPI for binding and implementation extensions?
Posted by ant elder <an...@gmail.com>.
On 5/31/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> ant elder wrote:
> > I was trying to update the extension writers guide on the wiki and
> > found it
> > really hard to say simply and clearly what (and why) each step is
> needed.
> > Now that there's quite a few extensions written to look at to see how
> > things
> > are being done I think we could simplify the SPI for these a bit moreby
> > having something like a new discoverable activator like this:
> >
> > public interface BindingActivator<B extends Binding> {
> > Class<B> getModelType();
> > StAXArtifactProcessor<B> getSCDLProcessor();
> > ReferenceBindingProvider
> > createReferenceBindingProvider(RuntimeComponent
> > rc, RuntimeComponentReference rcr, B b);
> > ServiceBindingProvider
> > createServiceBindingProvider(RuntimeComponent rc,
> > RuntimeComponentService rcs, B b);
> > }
> >
> > And then (borrowing an earlier idea from Sebastien) BindingActivator
> > impls
> > can use constructor args for any required extensions they need (eg
> > ServletHost) and the runtime automatically sets them without the impl
> > needing to explicitly locate them itself from the registry.
> >
> > This would make the extension code a lot simpler and more obvious and
> > clear
> > exactly what must be implemented, and it removes the dependency on the
> > ExtensionPointRegistry.
> >
> > All the old SPI continues to work, they would be like an advanced or
> > system
> > SPI, but simpler binding and implementation extensions could use this
> > more
> > simple interface.
> >
> > Any objections if I go ahead and try this?
> >
> > ...ant
> >
>
> +1, I think we could even go a little bit further and provide a
> simplification layer...
> - covering component implementation types as well as bindings
> - saving the extension developer from having to write an XML artifact
> processor, for simple cases we could introspect the binding model and
> simply map its fields to simple XML attributes.
> - hiding the ProviderFactory and Provider layers
>
> Ideally, for simple cases, I'd just want to write:
> - a Binding or Implementation type model class
> - an Invoker to handle invocations on SCA references
> - a Listener to handle start/stop and incoming SCA service invocations
> - a single Activator class tying the above together.
>
> This layer would not alter or replace the current SPI, it would just be
> a simplification convenience layer on top of the current pluggability
> story, covering simple binding and implementation type cases. I'd
> suggest to put this layer in different packages.
I've started an attempt at this keeping it completely separate from the
existing spi for right now by using a new extension-helper module. And i've
changed the script implementation and ajax binding to use it. Its only a
start and needs lot of work so anyone please feel free to comment, suggest
changes and alternatives, or just dive in with your own code.
...ant
Re: Even simpler SPI for binding and implementation extensions?
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> I was trying to update the extension writers guide on the wiki and
> found it
> really hard to say simply and clearly what (and why) each step is needed.
> Now that there's quite a few extensions written to look at to see how
> things
> are being done I think we could simplify the SPI for these a bit moreby
> having something like a new discoverable activator like this:
>
> public interface BindingActivator<B extends Binding> {
> Class<B> getModelType();
> StAXArtifactProcessor<B> getSCDLProcessor();
> ReferenceBindingProvider
> createReferenceBindingProvider(RuntimeComponent
> rc, RuntimeComponentReference rcr, B b);
> ServiceBindingProvider
> createServiceBindingProvider(RuntimeComponent rc,
> RuntimeComponentService rcs, B b);
> }
>
> And then (borrowing an earlier idea from Sebastien) BindingActivator
> impls
> can use constructor args for any required extensions they need (eg
> ServletHost) and the runtime automatically sets them without the impl
> needing to explicitly locate them itself from the registry.
>
> This would make the extension code a lot simpler and more obvious and
> clear
> exactly what must be implemented, and it removes the dependency on the
> ExtensionPointRegistry.
>
> All the old SPI continues to work, they would be like an advanced or
> system
> SPI, but simpler binding and implementation extensions could use this
> more
> simple interface.
>
> Any objections if I go ahead and try this?
>
> ...ant
>
+1, I think we could even go a little bit further and provide a
simplification layer...
- covering component implementation types as well as bindings
- saving the extension developer from having to write an XML artifact
processor, for simple cases we could introspect the binding model and
simply map its fields to simple XML attributes.
- hiding the ProviderFactory and Provider layers
Ideally, for simple cases, I'd just want to write:
- a Binding or Implementation type model class
- an Invoker to handle invocations on SCA references
- a Listener to handle start/stop and incoming SCA service invocations
- a single Activator class tying the above together.
This layer would not alter or replace the current SPI, it would just be
a simplification convenience layer on top of the current pluggability
story, covering simple binding and implementation type cases. I'd
suggest to put this layer in different packages.
Thoughts?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org