All we did to solve the issue was to move the provider class from one
project to another, keeping it in the same package.
The web.xml was already modified in the target project, so it must be
something else.
On Mon, Dec 19, 2011 at 23:04, Farrukh Najmi
<farrukh_at_wellfleetsoftware.com>wrote:
> **
>
> When in a similar situation before I found that any number of very easy
> mistakes can cause the detection of your provider to not work.
> In my case I tried turning on jersey message logging and that did not give
> me any clues. Eventually I had to use NetBeans debugger with compatible
> versions of jersey source to step through the code and find out the really
> dumb mistake I was making. Perhaps it was a typo in packagename specified
> <param-name>com.sun.jersey.config.property.packages</param-name>. I can't
> recall the details and they are likely not significant. What is significant
> from that experience is that I had to debug the jersey code to understand
> what was wrong.
>
>
> On 12/19/2011 03:38 PM, Ron wrote:
>
> Hi everyone,
>
> We've tried implementing our own custom MessageBodyReader which is based
> off on Jackson's JacksonJsonProvider.
>
> If I understand correctly, there are four possible ways to do so:
>
> 1. Use the @Provider annotation, with the appropriate @Consumes
> annotation to accompany it.
> 2. Explicitly add it to ResourceConfig.
> 3. Use the
> <param-name>com.sun.jersey.config.property.packages</param-name> init param
> in the web.xml.
> 4. Add it to the project's META-INF as an SPI module.
>
> Our application has several RESTful API projects, and they all depend on a
> commons-web project we have.
>
> Trying to get the application to recognize our custom MessageBodyReader,
> it seemed that no matter what we tried, we couldn't get Jersey to use our
> class. We tried the @Provider annotation and the web.xml config, but at no
> avail.
>
> Once we our class to one of the specific RESTful projects, it started
> working.
>
> I'm trying to understand the cause for this. As far as I can tell, there
> are two possible reasons: it's either the way Jersey decides on which
> provider to use for a mime-type (since there's now more than one provider
> for JSON - Jackon's and our own) or it's a class-loading order issue (which
> also may impact the first option).
>
> Can anyone explain the process of how Jersey decides which MBR to use for
> a content-type, and perhaps suggest a saner solution? Right now it seems
> the only way to make it work is duplicate the code (to an extent) in the
> various API projects.
>
> Thanks,
>
> Ron
>
>
>
> --
> Regards,
> Farrukh Najmi
>
> Web: http://www.wellfleetsoftware.com
>
>