cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Egerton <egg...@gmail.com>
Subject Re: Custom WSDL binding
Date Sat, 29 Jan 2011 19:43:45 GMT
Hi Benson,

Thank you for replying again.  My comments are inline below.

> a) Alan, while my name is on a lot of commits on this project, I'm not
> an expert on the further reaches of web services, and there are parts
> of the architecture that I've never immersed myself in. So it is
> entirely possible that Glen or Dan or someone will pop up any minute
> and show you a trail of breadcrumbs leading to just the sort of
> gingerbread house you are looking for.

On the contrary: it is my understanding of web services which has been
somewhat lacking and consequently I've been flailing around making
life overly complicated.  Your insight has been very helpful!

> For your one-time-pad example, advice here would be to write an
> interceptor and configure it on your endpoint. That just works. No
> WSDL, no 'binding', just customization of CXF's behavior. CXF has a
> very, very, open architecture for this sort of thing; you can stick
> some custom code in between just about any two activities you can
> think of. In fact, the implementation of a custom binding, I think,
> would involve building the runtime function as one or more
> interceptors, and then adding the wiring to automate their
> installation. The existing bindings are implemented as interceptors
> that do what needs to be done.

That's fantastic—I had completely missed interceptors (how, when they
are such a fundamental piece of CXF, escapes me).  Am I right in
thinking that, using wsdl2java with cxf-xjc-wsdlextension, such wiring
to automate installation into generated code based upon WSDL
extensions would be quite trivial?

Perhaps this should be in a separate thread, but to avoid inundating
the list: I've used wsdl2java to generate some initial client code
but, where a fault message comprises multiple parts, the arising fault
class contains duplicate fields and methods for each such part;
moreover, the class has duplicate @WebFault annotations.  Am I right
in thinking that the JAX-WS spec has assumed that no fault message
will have multiple parts and so there is nothing one can do to fix
this without (partially) dumping JAX-WS?

Cheers,
-- Alan

Mime
View raw message