Hi Gareth,

On 03/12/12 14:19, Gareth Hughes wrote:
Hi,

I'm trying to avoid using @XmlSeeAlso with my WebClient for unmarshalling
an XML Response.

If I setup @XmlSeeAlso on my root bean then all the unmarshalling works
properly and the inner classes that use a different namespace get built
properly. But, I've been trying to do the same thing using extraClass and
not getting it to work.

I'd doing this with Java Spring config files.

         JAXBElementProvider<Object>  p = new JAXBElementProvider<Object>();
         p.setSingleJaxbContext(true);
         p.setExtraClass(new Class[]{GovTalkMessage.class, IRenvelope.class,
ErrorResponse.class});
         List<Object>  providers = new ArrayList<Object>();
         providers.add(p);
         WebClient client = WebClient.create(URL, providers);


I've been diving into the code and looking at the code that uses the
extraClass. AbstractJAXBProvider.init() has

        JAXBContext context =
                 ResourceUtils.createJaxbContext(allTypes, extraClass,
cProperties);

and allTypes is derived from the List<ClassResourceInfo>cris. If cris is
null, the context is null.

cris ultimately comes from JAXRSClientFactoryBean classResourceInfos.  What
should that contain?

On the server side, and I think when using the proxy-based client code, this comes from introspecting the root resource classes, which is not available in case of WebClient.

That said, setting an extraClass property alone should also work, what exactly is happening ? Do you have interfaces in the above list of classes ?

thanks, Sergey


I should point out I'm using a custom outInterceptor. No other special
setup.

many thanks for any help

Gareth

Reply via email to