On Thursday 28 October 2010 6:17:23 am sebge2 wrote:
> Hello,
>
> When the WSDL is auto-generated, the only way to add (in the WSDL) a SOAP
> header entry is to declare an input param in the method.
>
> For instance: void myMethod(@WebParam(header=true) MySoapHeaderEntry entry)
>
>
> Unfortunately, it means that we have to declare the param in every method,
> in every webservice even if we are not using it. Indeed, if some web
> services are using the same header entry, it's stupid to pollute every
> methods of those WS. It's preferable to use an interceptor for that
> purpose. But, using an interceptor means that the WSDL is no more
> up-to-date.
>
> As far as I know, it's not possible to do that in CXF.
No, it's not, but you got me thinking.... :-)
> I'm right?
>
> Don't you think that it could be interesting to have that feature?
Definitely an interesting to have feature. Is it something you would be
willing to help out with?
My initial thought with 2.3.0 was to add a @SoapHeader annotation or similar
that would work something like:
SoapHeader( name = "ElmentName",
targetNamespace=".....",
[ partName = "...",]
[ type = SomeClass.class ],
[ typeName = "..."],
[ outOfBand = true/false],
direction=IN/OUT //maybe, not sure )
If added to the SEI or impl itself, it would apply to all methods in the
portType. When generating the wsdl, all the operations would have it added.
Otherwise, it could be added to the specific methods itself.
The name/targetNamespace would be used to assign the element name for the
header. The outOfBand would control if the header is mapped into the same
WSDL message as the body or if out of band messages would be created. The
type/typeName things would be used to Assign the "type" for the element. If
the class is specified, we SHOULD be able to use that at runtime for
marshalling/unmarshalling directly to the class.
What do you think? Willing to help on that? I can provide pointers of where
to start. :-)
--
Daniel Kulp
[email protected]
http://dankulp.com/blog
