I'd consider that a bug and log it JIRA. That should be unwrappable. Dan
On Tuesday September 19 2006 11:54 am, Dan Diephouse wrote: > Speaking of unwrapped operations, currently in JAX-WS we end up with one > way operations like: > > @Oneway > @RequestWrapper(targetNamespace = > "http://cxf.apache.org/greeter_control/types";, className = > "org.apache.cxf.greeter_control.types.GreetMeOneWay", localName = > "greetMeOneWay") > @WebMethod(operationName = "greetMeOneWay") > public void greetMeOneWay( > @WebParam(targetNamespace = > "http://cxf.apache.org/greeter_control/types";, name = "requestType") > java.lang.String requestType > ); > > However, this doesn't show up as isUnwrappedCapable with the current > WSDLServiceBuilder because it doesn't have an output message. This > causes problems when we create proxies (see the logic thats in > EndpointInvocationHandler right now). It seems like the simplest thing > to do is support one way unwrapped operations. Or we could have the > frontend go back through and modify the service wsdl What do you think? > > - Dan > > Daniel Kulp wrote: > >Guillaume, > > > >>I've raised a JIRA issue about wrapping informations [1]. > >>The wrapping informations for an operation is an effect of > >>the binding, not of the abstract operation. > >>All informations from the OperationInfo should be removed > >>and put in the BindingOperationInfo. > > > >Dan and I had a couple of long discussions about this earlier as well. > > The problem is that unwrapping/wrapping is not an effect for the binding > > either. It's technically completely and artifact of the frontend mapping. > > In some cases, the frontend may need/want the data to be unwrapped, but > > in other cases, it may not. > > > >For example, in JAX-WS, we need to support BOTH mappings of: > >int add(int a, int b) > >and > >AddResponse add(AddRequest req) > >that would map to the same WSDL. > > > >Originally, I was only going to have the "strict" OperationInfo in the > >ServiceModel that strictly represented the wsdl. (One MessagePartInfo in > > the message) After talking with Dan, we decide to make the "strict" > > form the normal one, but allow the frontend to "select" the unwrapped > > form, mostly as a convenience. > > > >>It seems that actually the only information needed is wether > >>the bound operation is wrappable or not, which should be > >>a simple boolean on the BindingOperationInfo > >> > >> boolean isUnwrapped() > >> > >>The WSDLServiceFactory should be modified accordingly to > >>detect wrapped operation when the binding is built and > >>set this boolean flag if only one part is bound to the soap body. > > > >The PROBLEM with this approach is that the "unwrapped capable" logic would > >need to be then embedded into ALL the bindings. The XML binding would > > need it, the CORBA binding (yoko project) would need it, other developer > > bindings would need it, etc... > > > >What we kind of decided on was to, again, for the "default/normal cases", > >autodetect if it matched the "normal" rules and flag it as unwrapped > > capable, but allow the binding and/or frontends to then also participate > > in that. Thus, adding some information to the soap binding to also detect > > the header cases is good, but I'd leave the stuff in the > > WSDLServiceFactory for the other cases. Also, a frontend would > > probably need to have a say in it. It currently COULD by modifying the > > service model after creation from the WSDL. For now, the JAX-WS layer > > can just select one of the two "forms" of the operation stored in the > > model that the WSDLServiceBuilder already provided. > > > >Enjoy! -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 F:781-902-8001 [EMAIL PROTECTED]
