cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <...@envoisolutions.com>
Subject Re: Tooling Proposal [was Re: tooling and service model]
Date Wed, 27 Sep 2006 20:07:17 GMT
I'm hacking away at that slowly:

http://cwiki.apache.org/confluence/display/CXF/Architecture+Guide

I've really only gotten through the more low level bits though. You 
should see some more in the next week or so.

- Dan

Bacon, Stephanos wrote:
> 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?
>
> -steph
>
>
> -----Original Message-----
> From: Liu, Jervis
> To: cxf-dev@incubator.apache.org <cxf-dev@incubator.apache.org>
> Sent: Wed Sep 27 13:34:56 2006
> Subject: RE: Tooling Proposal [was Re: tooling and service model]
>
>
>
>   
>> -----Original Message-----
>> From: Dan Diephouse [mailto:dan@envoisolutions.com]
>> Sent: 2006?9?27? 22:32
>> To: cxf-dev@incubator.apache.org
>> 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 DataBindingGenerator.java and 
>> FrontEndGeneratorsProfile.java.
>>     
>>> 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
>> http://envoisolutions.com
>> http://netzooid.com/blog
>>
>>
>>     
>
>   


-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog


Mime
View raw message