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: [email protected] <[email protected]>
Sent: Wed Sep 27 13:34:56 2006
Subject: RE: Tooling Proposal [was Re: tooling and service model]
-----Original Message-----
From: Dan Diephouse [mailto:[EMAIL PROTECTED]
Sent: 2006?9?27? 22:32
To: [email protected]
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
