On 4/30/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
ant elder wrote: > On 4/29/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> >> Author: jsdelfino >> Date: Sat Apr 28 16:52:22 2007 >> New Revision: 533445 >> >> URL: http://svn.apache.org/viewvc?view=rev&rev=533445 >> Log: >> Changes to make sure that model factories can be switched and the >> that the >> runtime does not assume specific factories or implementation classes. > > > Could you say a bit more about what this change is about? I'm not sure I > understand why its a good thing for all the extensions to now have to > hard > code all the default factories? > > ...ant > The change is about cleaning up the code which was hardcoding the model factories in various places in the runtime, and would basically make it impossible for an extension or a Tuscany runtime assembly to switch the model factories to others than the default ones. Initially, the factories were hardcoded by the processors, introspectors and various other pieces of the core runtime. Now the factories are not hardcoded by the core pieces of runtime anymore, and an extension can choose - to hardcode :) - a specific factory, including the default one. The idea is to allow the choice of factory to be externalized. Ideally it should be chosen by the SCA runtime assembler. For example if I want to assemble an SCA runtime integrated with Spring I should be able to choose the model factory that creates Component model objects backed by Spring bean definitions (like the factory in the tuscany-core-spring module). This was not possible before as a number of pieces of runtime were hardcoding a new DefaultAssemblyFactory() instead of having the factory "injected" - to use a trendy term :) - into them. This is now possible as the factory is now passed to (oops, injected into) them. Another example is that the Java module activator will probably want to use a specific factory to create model objects for its services, references. and properties augmented with Java specific info. For example for a Reference created by the Java class introspector, we'll probably want to have the Java member (method or field) defining the reference stored in the Reference model object. So in this case, the extension developer will actually be happy to be able to choose the factory to use. The Script implementation extension may be able to follow a similar approach to be able to use specific implementations of Service, Property or Reference that can carry script specific info as well. An option, for the script implementation for example, would be to continue to hardcode the factory inside its artifact processor, or construct instances of model implementations using "new" directly even without using a factory, but that will limit its reusability as it will basically tie it to a specific implementation of the assembly model.
So now in the Axis2 binding the start method of the Axis2ModuleActivator it news up a whole lot of factories - DefaultAssemblyFactory, DefaultPolicyFactory, DefaultWebServiceBindingFactory, DefaultWSDLFactory, DefaultWSDLInterfaceIntrospector, and the WebServiceBindingProcessor - none of those are used by the Axis2 binding and they tie the binding to the xml ws binding impl. Should binding.ws.xml have its own ModuleActivator that does all this? One thing I don't like so much is all those default factories have .impl. in package name and that makes it look like you're not using the SPI properly, how about moving all the default factories up to the top level package in their module? This may not be so relevant to this thread, but to get the Axis2 binding going I've added get/setInterfaceContract to the WebServiceBinding interface in binding.ws (to get the databinding working IIRC). I'm not sure that was the right thing to do now and it makes binding.ws.xml depend on the interface-wsdl-xml, does this look ok? ...ant
