After some digging, I finally fixed the issue. Here is how I did it.
Probably, there is a better way of doing this. But, here is my version and
this works .
Step I:
Extract the schema from the web service response. Generate jaxb entities
using the maven-jaxb2-plugin. (Ensure that the schema's namespace matches
the wrapper's element's namespace.
Step II:
Create a JAX-WS logical Handler. In the handleMessage method, grab the
payload as follows:
...;
LogicalMessage lm = context.getMessage();
Source payload = lm.getPayload();
...;
Step III:
Stripped all unwanted xsd:schema elements as shown in the previous post by
using nekohtml.
Step IV:
Created a jaxb context and unmarshalled the stripped response.
The logical handler is configured via the uri options as follows:
cxf://<url>?serviceName=<serviceName>&portName=<portName>&wsdlURL=<wsdlURL>&defaultOperationName=<defaultOperationName>&serviceClass=<serviceClass>&*handlers=#cxfhandlers*
The #cxfhandlers will look up the registry with bean id = "cxfhandlers".
The cxfhandlers bean is defined as follows:
<bean class="com.example.ListFactoryBean" id="cxfhandlers" >
<property name="classes">
<list>
<value>com.example.DataHandler</value>
</list>
</property>
</bean>
The ListFactoryBean is a factory bean which returns a list of objects
implementing the handler interface.
With these, I was able to get the response as a JaxB object.
best regards
Sriraman.
--
View this message in context:
http://camel.465427.n5.nabble.com/Camel-CXF-component-Adding-custom-context-classes-via-the-uri-options-tp5726313p5726403.html
Sent from the Camel - Users mailing list archive at Nabble.com.
