You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by ant elder <an...@gmail.com> on 2007/05/01 12:14:53 UTC
Re: svn commit: r533445 [1/4] - in /incubator/tuscany/java/sca: itest/contribution/src/test/java/org/apache/tuscany/sca/test/contribution/ modules/assembly-java-dsl/src/main/java/org/apache/tuscany/assembly/builder/impl/ modules/assembly-xml/src/main
On 4/30/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> ant elder wrote:
> > On 4/29/07, jsdelfino@apache.org <js...@apache.org> 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
Re: svn commit: r533445 [1/4] - in /incubator/tuscany/java/sca: itest/contribution/src/test/java/org/apache/tuscany/sca/test/contribution/ modules/assembly-java-dsl/src/main/java/org/apache/tuscany/assembly/builder/impl/ modules/assembly-xml/src/main
Posted by ant elder <an...@gmail.com>.
On 5/2/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> ant elder wrote:
> > On 5/1/07, Jean-Sebastien Delfino <js...@apache.org> 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
Re: svn commit: r533445 [1/4] - in /incubator/tuscany/java/sca: itest/contribution/src/test/java/org/apache/tuscany/sca/test/contribution/
modules/assembly-java-dsl/src/main/java/org/apache/tuscany/assembly/builder/impl/
modules/assembly-xml/src/main
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> On 5/1/07, Jean-Sebastien Delfino <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: svn commit: r533445 [1/4] - in /incubator/tuscany/java/sca: itest/contribution/src/test/java/org/apache/tuscany/sca/test/contribution/ modules/assembly-java-dsl/src/main/java/org/apache/tuscany/assembly/builder/impl/ modules/assembly-xml/src/main
Posted by ant elder <an...@gmail.com>.
On 5/1/07, Jean-Sebastien Delfino <js...@apache.org> 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
Re: svn commit: r533445 [1/4] - in /incubator/tuscany/java/sca: itest/contribution/src/test/java/org/apache/tuscany/sca/test/contribution/
modules/assembly-java-dsl/src/main/java/org/apache/tuscany/assembly/builder/impl/
modules/assembly-xml/src/main
Posted by Jean-Sebastien Delfino <js...@apache.org>.
[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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org