Hi Markus,
On 07/13/2011 06:45 PM, Markus Karg wrote:
> Jakub,
>
> I found the time to analyze our code, and was lucky to find a workaround:
>
>
> If I do not return a Custom JAXB class (for which Jersey must
> find our ContextResolver -- which obviously does not work as I
> already mentioned) but instead use the below code to manually
> provide a String, everything is working well even in
> GFv3.1.1_b11. :-)
I agree generating the XML string manually is annoying.
>
>
> But certainly I am highly interested in the actual cause, why
> Jersey is not finding our context resolver? I expect the
> problem is that we have to return application/xml, which is
> also provided by Jersey's own context resolvers. So how can we
> convince Jersey that even in GF (outside it works!) it shall
> use *our* context resolver to marshal that Custom JAXB class?
> Or in other words, how to convice Jersey's own context
> resolver that it shall *not* marshall our custom JAXB class?
The default marshaling process flow is like follows:
1. Jersey tries to obtain a JAXB Marshaller instance
(via custom ContextResolver<Marshaller>) first
If succeeded, the marshaller is used to marshal the data
2. if the above marshaller is not available
(missing resolver|resolver returns null)
Jersey tries to get a JAXBContext instance
(via ContextResolver<JAXBContext>)
in order to get a JAXB marshaller from it.
if there is no custom JAXBContext available,
the default one for the given Java type is used:
JAXBContext.newInstance(type)
Attaching a zipped web application with a custom JAXBContext
resolver and two JAXB beans. Things work fine for me here
on GFv3.1 and also GFv3.1.1 b10.
The ContaineeBean context is configured
to use "anotherNS" instead of the default one,
and that works fine:
--8<--
curl -XPOST -HAccept:application/xml \
-HContent-type:application/xml \
--data '<ns2:containeeBean
xmlns:ns2="anotherNs"><content>foo</content></ns2:containeeBean>' \
http://localhost:8080/jaxb-context/webresources/containee
<?xml version="1.0" encoding="UTF-8"
standalone="yes"?><containerBean><containee><content>foo</content></containee></containerBean>
-->8--
Is it possible to send out similar test case application,
where the issue reproduces?
~Jakub
>
>
> Thanks
>
>
> Markus
>
> *From:*Jakub Podlesak [mailto:jakub.podlesak_at_oracle.com]
> *Sent:* Dienstag, 12. Juli 2011 17:59
> *To:* users_at_jersey.java.net
> *Subject:* [Jersey] Re: Jersey fails in GFv3.1
>
> Hi Markus,
>
> That is really strange. Given that the very same application
> works fine on GFv2 it might be related to some GFv3 class-loading magic.
> Any chance you could isolate a small simple
> reproducible test case to share?
>
> The only other option i can think of at the moment is you may try
> to re-bundle your application, remove all Jersey jars from it
> and try to redeploy. Does the issue reproduce then?
>
> ~Jakub
>
>
>
> On 07/12/2011 03:01 PM, Markus Karg wrote:
>
> [Crossposted to GlassFish Forum]
>
> Our JAX-RS application is working well standalone (Grizzly) as well as
> in GFv2ur2 (Jersey-1.4 bundled in our EAR), but fails in GFv3.1
> (Jersey-1.5 is part of GF)!
>
> In particular, we are providing a custom ContextResolver which provides
> (besides more) two classes: "QuerySchemaDiscovery" and
> "BasicSearchSchema". Within "getContext" we are doing some output to see
> what class was requests (for debug purposes).
>
> Our resource method receives a "QuerySchemaDiscovere" instance (i. e.
> JAXB can resolve it using our custom ContextResolver), then wants to
> return an instance of "BasicSearchSchema". And here is the funny thing:
> GFv3.1 says that "BasicSearchSchema" is not part of the JAXB context.
> Moreover, there is a log entry found for
> "getContext(QuerySchemaDiscovere)" but NOT for
> "getContext(BasicSearchSchema)", so obviously is seems GFv3.1 is using a
> differen context...
>
> Caused by: javax.xml.bind.JAXBException: class
> net.java.dev.webdav.jaxrs.search.xml.elements.BasicSearchSchema nor any
> of its super class is known to this context.
> at
> com.sun.xml.bind.v2.runtime.JAXBContextImpl.getBeanInfo(JAXBContextImpl.java:611)
> at
> com.sun.xml.bind.v2.runtime.property.ArrayReferenceNodeProperty.serializeListBody(ArrayReferenceNodeProperty.java:112)
> ... 56 more
>
> I cannot believe that it is a bug in my application, as it runs standone
> and in GFv2ur2, so I think it is a bug in GFv3.1. Any ideas what to do?
>
> Thanks!
>
> Markus
>