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