On 5/31/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> 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
