On 5/2/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
ant elder wrote: > On 5/1/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: >> >> [snip] >> ant elder wrote: >> > >> > 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 >> >> What you're describing here is an assembly, described before in SCDL, >> now built in Java code. This is basically the role of a ModuleActivator: >> assemble the pieces required for a particular extension. >> >> This is not just for factories, WSDLInterfaceIntrospector, >> WebServiceBindingProcessor, JavaInterfaceIntrospector, >> JavaClassIntrospector, our default InterfaceContractMapper, the default >> databinding Mediator are all in the same category. They are newed up at >> the edges of our runtime, in SimpleRuntimeImpl or in the ModuleActivator >> of an extension, and assembled there. >> >> > - 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? >> >> I would be fine with moving this assembly logic out of the >> Axis2ModuleActivator, but it needs to be done somewhere :) The work I >> did recently to push these assembly decisions to the edges should now >> make it easier to put this assembly logic anywhere we want, and should >> allow us to not be tied to a specific implementation of binding.ws for >> example and select it in the assembly - at the top of the stack - as >> opposed to having it hardcoded in the lower runtime layers like before. > > > So how about I add a ModuleActivator to binding-ws-xml to do it seeing > thats > what the assembly is for? Or does it need another completely seperate > module? Module binding-ws-xml does not depend on core-spi. The idea is to keep it independent of the rest of the core runtime to make it easier to reuse by other projects who will want to support the SCA assembly XML syntax, without necessarily integrating the Tuscany core runtime.
Ah, ok I'd forgotten that so all this makes a lot more sense to me now. Thanks for the long explanations. ...ant
