Hi Marek,
I'm fairly certain this is not a classpath issue. The project is managed
with maven and the dependant project is included in the resulting war file.
It seems to be a matter of classloading priority. I think it's related to
how jersey decides which provider is used for the content type when there
are multiple options available.
From what I've seen, in resteasy it is possible to set the custom class
with an additional annotation that declares it as a higher priority.
What I'm trying to find out is how jersey decides this priority and what
options do I have, and if any, to control it.
Thanks,
Ron
בתאריך 2011 12 20 11:43, מאת "Marek Potociar" <marek.potociar_at_oracle.com>:
> What you describe looks like a class-path issue. Please make sure that
> class-path of your projects is properly set up,
> to include the provider implementation. Otherwise Jersey will not be able
> to find it, which may be the root cause of the
> behavior you are experiencing.
>
> Marek
>
> On 12/20/2011 06:46 AM, Ron wrote:
> > 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 <mailto: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
> >
> >
>