modify wsdl / request / response via interceptor

[Will Johnson <wi...@gmail.com>]

I'm trying to figure out how to manipulate a web service such that I can
support some client development environments that can't handle certain XSD
element types.  For instance: I'd like to dynamically replace the following
in my wsdl:

 

<xs:element minOccurs="0" name="value" type="xs:anyType"/>

 

With

 

<xs:element minOccurs="0" name="value" type="xs:string"/>

 

This needs to happen:

 

* at WSDL generation time - ie the client sees the xsd:string version

* at request time - the request assuming a string needs to be translated to
specify that it is always a string

* at response time - the response needs to take the string value of whatever
comes out and treat it accordingly.

 

I need to make sure that clients can choose to enable or disable this
ability as most development environments can handle the any type but a few
older gui driven platforms aren't as forgiving.  From the basic
investigation I've done it looks like an interceptor is what I'm looking for
but I'm having a hard time find a good starting point.  

 

Any help/pointers would be appreciated.

 

-          will

Re: modify wsdl / request / response via interceptor

[eanbiso <bi...@hotmail.it>]

Hi all,
I must change the content of the response obtained at 
?wsdl
invocation.
I'm using cxf 2.7.3.
I've tried different solutions but with poor results:
1. I've tried to extend the WSDLGetInterceptor but, if I'm not mistaken,
this interceptor is recalled before the response is properly built: i.e.
this is not the right way.
2. I've created a specific WSDLQueryHandler, implementing the interface
StemMatchingQueryHandler (you can find it as attached file
"WSDLQueryHandler.java.txt"), and I've added it to the at ws publication in
this way:

   EndpointImpl eimpl = null;
   .....
   QueryHandlerRegistryImpl handlerReg = new
QueryHandlerRegistryImpl(eimpl.getBus());
   handlerReg.registerHandler(new WSDLQueryHandler(eimpl.getBus()));

Now, at ?wsdl invocation, I arrive in the 
   writeResponse(..)
of the class, but something fails executing this operation:

   WSDLWriter wsdlWriter = bus.getExtension(WSDLManager.class)
                        .getWSDLFactory().newWSDLWriter();

and no content is returned at the invocation.
What am I doing wrong?
Which is the cleanest way, using cxf 2.7.3, to change the response obtained
at ?wsdl invocation ?

Thanks in advance,

Andrea



--
View this message in context: http://cxf.547215.n5.nabble.com/modify-wsdl-request-response-via-interceptor-tp2834190p5746795.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: modify wsdl / request / response via interceptor

[Sergey Beryozkin <sb...@gmail.com>]

You can try implementing

org.apache.cxf.transports.http.QueryHandler

which would support ?wsdl queries and delegate to

org.apache.cxf.transport.http.WSDLQueryHandler.

In its writeResponse() implementation you might try replacing the
OutputStream with the one which would be at the top of the XSLT chain and
transform or drop certain xsd elements as needed,

just one possible option to experiment with, there could be more effective
ones

cheers, Sergey

On Thu, Sep 9, 2010 at 10:28 PM, Will Johnson
<wi...@gmail.com>wrote:

> I'm trying to figure out how to manipulate a web service such that I can
> support some client development environments that can't handle certain XSD
> element types.  For instance: I'd like to dynamically replace the following
> in my wsdl:
>
>
>
> <xs:element minOccurs="0" name="value" type="xs:anyType"/>
>
>
>
> With
>
>
>
> <xs:element minOccurs="0" name="value" type="xs:string"/>
>
>
>
> This needs to happen:
>
>
>
> * at WSDL generation time - ie the client sees the xsd:string version
>
> * at request time - the request assuming a string needs to be translated to
> specify that it is always a string
>
> * at response time - the response needs to take the string value of
> whatever
> comes out and treat it accordingly.
>
>
>
> I need to make sure that clients can choose to enable or disable this
> ability as most development environments can handle the any type but a few
> older gui driven platforms aren't as forgiving.  From the basic
> investigation I've done it looks like an interceptor is what I'm looking
> for
> but I'm having a hard time find a good starting point.
>
>
>
> Any help/pointers would be appreciated.
>
>
>
> -          will
>
>