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. To
avoid tieing modules together this assembly code is probably better kept
at the very edge/top of the stack.
I understand that having to new up the factories in Axis2ModuleActivator
extension is not great, but I think it's just a point in time
limitation. There are many ways to change that:
a) Move the assembly to an entirely different module. but it's still not
great to hardcode the selection of factories, introspectors etc. there
either
b) Move the DefaultXyzFactory classes out of an impl package and into an
SPI package, this is mostly cosmetics and does not really change the pattern
c) Have XyzFactory abstract factory classes with a static newInstance()
method to new up the DefaultXyzFactory
d) Have the XyzFactory abstract factory classes externally configurable,
allowing you to keep the factory selection out of the extension
e) Have SimpleRuntimeImpl (which creates most factories) pass them to
the constructor or some setter methods of the ModuleActivators
f) Define a ModelFactory extension point and have the ModuleActivator do
extensionPoint.getFactory(XyzFactoryInterface.class) to get a factory
g) Use an IoC container to pass the factories to the ModuleActivators as
a fancy way to do (e).
I think we should give it a little bit of time before jumping to
implement one of these patterns, and first observe what factories or
other similar common objects are actually needed in most extension
ModuleActivators over time.
If you think that the current pattern (having to new up the factories
and a few other objects in the ModuleActivators) is problematic, I'd
suggest to implement options (e) or (f).
> 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?
Sorry I was not clear. We could do one of the following:
- change XyzFactory to a XyzFactory class
- change XyzFactory to an abstract class with XyzFactory.newInstance()
creating a DefaultXyzFactory
- have a configurable XyzFactory abstract class
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
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
