You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Coder One <co...@yahoo.com> on 2010/08/11 03:29:55 UTC
Multiple WSDL / Common Code
On the server end, my webservices (separate interfaces/classes) share a common
set of domain classes.
Generating code (using cxf ws plugin) will generate duplicate copies of the
domain classes, albeit in different packages. Is there a way to have the plugin
to be smart enough to reuse the domain classes? In essence, I would end up with
multiple generated interface code, but they would all share the same set of
common domain classes for request/response, various parameters and such...
Thanks...
Re: Multiple WSDL / Common Code
Posted by Daniel Kulp <dk...@apache.org>.
On Tuesday 10 August 2010 9:29:55 pm Coder One wrote:
> On the server end, my webservices (separate interfaces/classes) share a
> common set of domain classes.
>
> Generating code (using cxf ws plugin) will generate duplicate copies of the
> domain classes, albeit in different packages.
Well, if you map the namespaces to the same package, that wouldn't occur.
They would be regenerated, but they should be exactly the same.
> Is there a way to have the
> plugin to be smart enough to reuse the domain classes?
JAXB has a concept of episode files where you could use xjc or something to
generate the classes and create an episode file and then have CXF pick that
up. However, it doesn't always work as when an episode is avail, JAXB doesn't
bother parsing the schema completely and certain information isn't available
that we need to create the interface.
In general, if you use a JAXB bindings file, you can have one wsdl2java run
process and generate all the code (no binging file), then for the others,
provide a binding file with a <schemaBindings map="false"> setting to tell it
to not generate for that schema.
Dan
> In essence, I
> would end up with multiple generated interface code, but they would all
> share the same set of common domain classes for request/response, various
> parameters and such...
>
> Thanks...
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog