These changes are an improvement, but they don't fully address my
concerns. It is still necessary for the xxxBindingProviderFactory
to extend from xxxBindingImpl, which itself extends from BindingImpl.
I think it would be better to avoid the need to extend from
BindingImpl, which is an implementation class in the
org.apache.tuscany.assembly.impl package and therefore presumably
not really intended for direct use by extension code.
Simon
Jean-Sebastien Delfino wrote:
ant elder wrote:
The script implementation has now been ported over to these new SPIs
and all
seems to be ok and the calculator-script sample works now. The new
SPIs seem
to me vastly better than what we had before. There's still some things I
think could be done to make it even easier to write an implementation, in
the script impl I've pulled out a few classes into a separate spi package
for code I thought the script impl shouldn't need to code itself, and
theres
also a few TODO comments in the rest of the code. Code people take a look
and comment on those classes and TODO comments to see if there's
things we
could improve?
...ant
Ant,
I integrated some of your comments and some of Simon's comments in this
thread, plus a few more simplications of the runtime SPIs under revision
r536114.
The main changes are:
- ImplementationProviders and BindingProviders can now be separate from
the assembly model objects.
- They are associated with their respective Component, ComponentService
and ComponentReference, which are given to them at creation time, so
there is no need to pass these to most methods anymore.
- Implementation and Binding extensions do not need to implement
Interceptor anymore, they implement a simpler Invoker interface.
- There's now a single ProviderActivator interface instead of three, and
the three Provider interfaces extend it.
Two of your comments are not covered yet:
- Merging componentTypes, I'd suggest a side util class to do this,
instead of a base Abstract class which may clutter/hide the interface
contract. We have a CompositeBuilder, maybe we could have a similar
ComponentTypeBuilder class.
- Creating proxies. As you suggested we could add a createProxy method
to RuntimeComponentReference.
Hope this helps.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
