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