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 >