Alan,

Better start a new thread for your question at the bottom. I can't
answer it. Otherwise, I think you're on track.

On Sat, Jan 29, 2011 at 2:43 PM, Alan Egerton <egg...@gmail.com> wrote:
> 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
>

Reply via email to