On 04/12/12 15:50, Gareth Hughes wrote:
Many thanks,
but I don't see the commit against the Jira item and I don't see any
commits on this through Fisheye. Did you commit to a Git repo and it's not
been pulled into the SVN repo?
For some reasons I did not see any info there too, here is the actual
commit:
http://svn.apache.org/viewvc?rev=1416953&view=rev
Cheers, Sergey
On 4 December 2012 14:25, Sergey Beryozkin<[email protected]> wrote:
I've done some improvements (as such merged to 2.6.x and the trunk - let
me know if the update is needed at 2.5.x):
https://issues.apache.org/**jira/browse/CXF-4672<https://issues.apache.org/jira/browse/CXF-4672>
The immediate workaround is to add a jaxb.index file and if if that does
not help - overriding getPackageContext same as it is done for CXF-4672
(should be visible from the JIRA tabs though I do not see it right now, or
check the source).
After the releases (in the next few days) setting an 'extraClass' property
only will work for package contexts too.
Or you can do provider.init(null) - this will also work if extraClass
property has been set - you'd only need to set one more property,
"useSingleContextForPackages" so that the single context can be associated
with the packages of all the involved classes early .
HTH, Sergey
On 04/12/12 10:34, Gareth Hughes wrote:
I've been debugging this morning and have made the same progress as you.
I'm pretty certain that extraClass isn't used and that getPackageContext()
might be the key to this.
Here's my stacktrace:
(IRenvelope is one of the inner classes contained by the main
GovTalkMessage class and has a different namespace)
[javax.xml.bind.JAXBException: class com.mycompany.util.hmrc.mov.**
IRenvelope
nor any of its super class is known to this context.]
at
com.sun.xml.bind.v2.runtime.**MarshallerImpl.write(**
MarshallerImpl.java:326)
at
com.sun.xml.bind.v2.runtime.**MarshallerImpl.marshal(**
MarshallerImpl.java:251)
at
javax.xml.bind.helpers.**AbstractMarshallerImpl.**marshal(**
AbstractMarshallerImpl.java:**110)
at
org.apache.cxf.jaxrs.provider.**JAXBElementProvider.**
marshalToOutputStream(**JAXBElementProvider.java:546)
at
org.apache.cxf.jaxrs.provider.**JAXBElementProvider.marshal(**
JAXBElementProvider.java:504)
at
org.apache.cxf.jaxrs.provider.**JAXBElementProvider.marshal(**
JAXBElementProvider.java:396)
at
org.apache.cxf.jaxrs.provider.**JAXBElementProvider.writeTo(**
JAXBElementProvider.java:268)
at
org.apache.cxf.jaxrs.utils.**JAXRSUtils.writeMessageBody(**
JAXRSUtils.java:1173)
at
org.apache.cxf.jaxrs.client.**AbstractClient.writeBody(**
AbstractClient.java:398)
at
org.apache.cxf.jaxrs.client.**WebClient$BodyWriter.**
doWriteBody(WebClient.java:**1003)
at
org.apache.cxf.jaxrs.client.**AbstractClient$**AbstractBodyWriter.**
handleMessage(AbstractClient.**java:932)
at
org.apache.cxf.phase.**PhaseInterceptorChain.**doIntercept(**
PhaseInterceptorChain.java:**271)
at
org.apache.cxf.jaxrs.client.**AbstractClient.**doRunInterceptorChain(**
AbstractClient.java:576)
at
org.apache.cxf.jaxrs.client.**WebClient.doChainedInvocation(**
WebClient.java:893)
at org.apache.cxf.jaxrs.client.**WebClient.doInvoke(WebClient.**
java:761)
at org.apache.cxf.jaxrs.client.**WebClient.doInvoke(WebClient.**
java:748)
at org.apache.cxf.jaxrs.client.**WebClient.invoke(WebClient.**
java:355)
at org.apache.cxf.jaxrs.client.**WebClient.post(WebClient.java:**
381)
On 4 December 2012 10:09, Sergey Beryozkin<[email protected]**>
wrote:
On 03/12/12 19:11, Gareth Hughes wrote:
No they are not interfaces. They are all xjc generated classes from
schemas.
I'm pretty sure that the jaxb provider is not using the extra class
settings but am at home and will provide more detail tomorrow. Where
could
I debug to see it in action decoding a response back to my object?
Sure, try org.apache.cxf.jaxrs.provider.****AbstractJAXBProvider#**
getClassContext
Actually, I wonder, is that code actually used or not.
Do you have ObjectFactory somewhere ? I'll experiment at my end, but I
can
see now that if package-level JAXB context is created then
AbstractJAXBProvider#****getClassContext is not called and thus
extraClass[] is not visible...
Sergey
Thanks
On 3 Dec 2012 16:54, "Sergey Beryozkin"<sberyozkin@gmail.****com<
[email protected]>>
wrote:
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
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
