users@jersey.java.net

[Resend] ContextResolver<JAXBContext> & Logging question

From: MHeinzmann <gnubaer-dontcare_at_yahoo.de>
Date: Tue, 05 Oct 2010 12:43:50 +0200

Hi everyone,

sorry for bothering you guys again, but my computer's time was wrong and
hence the timestamp of my original email. I hope you can forgive me my
repost. ;-)

On the way to finding out why JAXB marshalls the content of the
WebApplicationException with a fully qualified classname as tag, I would
like to know if our ContextResolver<JAXBContext> is used.

To do so I added the following logging level setting to glassfish's
logging.properties.:

    javax.ws.rs.level=FINE
    com.sun.jersey.level=FINE
    javax.xml.bind.level=FINE
    com.sun.xml.bind.level=FINE

Still I don't see any registration message of our ContextResolver. Just
to make sure that I am not changing the wrong logger levels, I went one
level further up, e.g. javax.ws instead of javax.ws.rs and tried again.
But all I see are lots of Providers for different Interfaces and not the
ContextResolvers for JAXBContexts.

So first question: Am I outputting the wrong packages?

Secondly, in order to make the ContextResolver known to Jersey, I added
our ContextResolver via javax.ws.rs.core.Application.getClasses()
method, do I need to do anything else that I might have missed?

And lastly, has anybody here on the list faced the same problem in which
the entity of the WebApplicationException's response was marshalled via
JAXB with a fully qualified class name as the tag (instead of the simple
name)?

Thankfully awaiting any kind of help/suggestion
 M. Heinzmann

P.S. I do know that, as a workaround, it is possible to define the name
of the tags used by JAXB via the @XmlRootElement tag. But this is a
workaround and not a proper solution.

P.P.S. We are using Glassfish 3.0.1 with Jersey 1.1.5 01/20/2010 04:04 PM.