[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.
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.
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?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
