cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bacon, Stephanos" <>
Subject Re: Tooling Proposal [was Re: tooling and service model]
Date Wed, 27 Sep 2006 19:45:55 GMT
Are these architecural elements (databinding, front ends, core, etc), their relationships and
invariants written up somewhere to help people get up to speed on how cxf works?


-----Original Message-----
From: Liu, Jervis
To: <>
Sent: Wed Sep 27 13:34:56 2006
Subject: RE: Tooling Proposal [was Re: tooling and service model]

> -----Original Message-----
> From: Dan Diephouse []
> Sent: 2006?9?27? 22:32
> To:
> Subject: Re: Tooling Proposal [was Re: tooling and service model]
> Liu, Jervis wrote:
> > Hi Dan K, I am completely on your side too. :-) I believe 
> we can all agree with followings:
> >
> > 1. The tools module is the framework and should not bind 
> into specific data bindings and frontends in its core. Data 
> bindings and frondends specific generators are loaded in the 
> runtime as plugins.  Tools module does not need to depend on 
> databinding and frontend during building. This feature is 
> already in tools, see and 
> >
> > 2. The plugins for the tools that actually do the 
> generation work should live in the appropriate place. JAXB 
> code goes in the JAXB databinding. JAX-WS stuff goes into the 
> JAX-WS frontend.
> >
> > 3. We do need to fix those non-jaxws modules that use any 
> JAX-WS specific generated codes.
> >
> > However, this does not answer two questions below:
> >
> > 1. How to use JAX-WS generated code in JAX-WS froentend 
> test if tools depend on rt?
> >
> >   
> We should be able to do some classpath mangling to get it 
> working. I was 
> able to do so with XFire and Maven using the maven ant 
> plugin. There may 
> be other/better ways though.
> > 2. Can we refactor tools to use serviceModel while still 
> keeping tools module as a top level module? I still believe 
> it does NOT make sense to make tools depend on the whole cxf 
> core just because it needs serviceModel. 
> >
> >   
> I don't think so. Even if you could, its not worthwhile 
> because you'll 
> need core because the JAX-WS module will depend on it.
> > Can we do sth to serviceModul similiar as what we have done 
> in tools? I.e., make serviceModel itself a generic model so 
> that anything using serviceModel does not need to depend on 
> specific databindings and frontend during build time. In the 
> run time, serviceModel acquires specific binding/frontend 
> capabilities through plugin loader. For example, a 
> JaxwsServiceModelBuilder that can decorate serviceModel using 
> info from Jax-ws annotations can be loaded by serviceModel in 
> the runtime. JaxwsServiceModelBuilder should live in Jax-ws frontend.
> >
> >   
> I'm confused, the servicemodel already doesn't depend on a sepcific 
> databinding. So I'm not sure what it is that you're suggesting...
What I proposed is making serviceModel a top level module, which does not depend on any frontend
from rt. So the core servicemodel can use an input of wsdl or class to generate generic model
info, in this case, some basic "auxillary classes" will be part of core serviceModel, such
as  org.apache.cxf.wsdl11.WSDLServiceBuilder and org.apache.cxf.soap.SoapBindingFactory. Both
WSDLServiceBuilder  and SoapBindingFactory should not have anything bind to core, if they
do, they need to be fixed. The frontend specific "auxillary classes" for example org.apache.cxf.jaxws.JaxWsServiceFactoryBean
is not part of core serviceModel, but gets loaded during runtime as plugin to extend serviceModel.
This is very similar to what we have done to tools using FrondendProfile. 

This way serviceModel becomes a top level model that both tools and rt can depend on, and
the serviceModel does not need to know anything about rt during the build time. Frontend factories
are loaded during runtime as plugins. 

> - Dan
> -- 
> Dan Diephouse
> Envoi Solutions

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message