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?
> 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? Yes, good idea. How about renaming DefaultXyzFactory to XyzFactory, and having a newInstance() method on it.
But there's already XyzFactory interfaces in the top level package so wont that clash, or am i missing what you're suggesting? I also think that we need a way for the runtime bootstrap code to select
some of these core pieces (a factory, an introspector, a mediator etc.) and have the extensions pick that selection instead of making their own selection... without turning it into a static singleton :) We can probably do this in a second step when we have a good view of what pieces are usually assembled by what kind of extension, and what falls under the responsiblity of the runtime or host assembler vs the extension developer. > > 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 > It's not too bad to have binding-ws.xml depend on interface-wsdl-xml I think, but could you describe why you needed the get/setInterfaceContract? Isn't the interface contract known from the reference or service using the binding?
I can't remember :) I just had a TODO note questioning it. I'll go dig about... ...ant
