Discussion:
Custom MessageBodyReader
Ron
2011-12-19 20:38:50 UTC
Permalink
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
Farrukh Najmi
2011-12-19 21:04:55 UTC
Permalink
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.
Post by Ron
Hi everyone,
We've tried implementing our own custom MessageBodyReader which is
based off on Jackson's JacksonJsonProvider.
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
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
Ron
2011-12-20 05:46:44 UTC
Permalink
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
Post by Farrukh Najmi
**
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.
Hi everyone,
We've tried implementing our own custom MessageBodyReader which is based
off on Jackson's JacksonJsonProvider.
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
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
Marek Potociar
2011-12-20 09:43:14 UTC
Permalink
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
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.
__
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.
Post by Ron
Hi everyone,
We've tried implementing our own custom MessageBodyReader which is based off on Jackson's JacksonJsonProvider.
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,
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
Ron
2011-12-20 11:51:46 UTC
Permalink
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
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
Post by Ron
All we did to solve the issue was to move the provider class from one
project to another, keeping it in the same package.
Post by Ron
The web.xml was already modified in the target project, so it must be
something else.
Post by Ron
On Mon, Dec 19, 2011 at 23:04, Farrukh Najmi <
__
When in a similar situation before I found that any number of very
easy mistakes can cause the detection of your
Post by Ron
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
Post by Ron
NetBeans debugger with compatible versions of jersey source to step
through the code and find out the really dumb
Post by Ron
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
Post by Ron
significant. What is significant from that experience is that I had
to debug the jersey code to understand what was
Post by Ron
wrong.
Post by Ron
Hi everyone,
We've tried implementing our own custom MessageBodyReader which is
based off on Jackson's JacksonJsonProvider.
annotation to accompany it.
Post by Ron
Post by Ron
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.
Post by Ron
Post by Ron
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.
Post by Ron
Post by Ron
Trying to get the application to recognize our custom
MessageBodyReader, it seemed that no matter what we tried,
annotation and the web.xml config, but at no avail.
Post by Ron
Post by Ron
Once we our class to one of the specific RESTful projects, it
started working.
Post by Ron
Post by Ron
I'm trying to understand the cause for this. As far as I can tell,
there are two possible reasons: it's either the
Post by Ron
Post by Ron
way Jersey decides on which provider to use for a mime-type (since
there's now more than one provider for JSON -
Post by Ron
Post by Ron
Jackon's and our own) or it's a class-loading order issue (which
also may impact the first option).
Post by Ron
Post by Ron
Can anyone explain the process of how Jersey decides which MBR to
use for a content-type, and perhaps suggest a
Post by Ron
Post by Ron
saner solution? Right now it seems the only way to make it work is
duplicate the code (to an extent) in the
Post by Ron
Post by Ron
various API projects.
Thanks,
Ron
--
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com
Jakub Podlesak
2011-12-20 15:00:33 UTC
Permalink
Hi Ron,

Application provided MBRs should always take precedence,
otherwise the ordering is not guaranteed by Jersey.

I.e. you would need to add your MBR class explicitly to your ResourceConfig
or Application class.

If you are not sure, could you please share your web.xml or
ResourceConfig/Application code,
so that i may suggest how to fix that?

Thanks,

~Jakub
Post by Ron
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"
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
Post by Ron
All we did to solve the issue was to move the provider class
from one project to another, keeping it in the same package.
Post by Ron
The web.xml was already modified in the target project, so it
must be something else.
Post by Ron
On Mon, Dec 19, 2011 <tel:2011> at 23:04, Farrukh Najmi
__
When in a similar situation before I found that any number
of very easy mistakes can cause the detection of your
Post by Ron
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
Post by Ron
NetBeans debugger with compatible versions of jersey source
to step through the code and find out the really dumb
Post by Ron
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
Post by Ron
significant. What is significant from that experience is
that I had to debug the jersey code to understand what was
Post by Ron
wrong.
Post by Ron
Hi everyone,
We've tried implementing our own custom MessageBodyReader
which is based off on Jackson's JacksonJsonProvider.
Post by Ron
Post by Ron
If I understand correctly, there are four possible ways to
@Consumes annotation to accompany it.
Post by Ron
Post by Ron
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.
Post by Ron
Post by Ron
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.
Post by Ron
Post by Ron
Trying to get the application to recognize our custom
MessageBodyReader, it seemed that no matter what we tried,
Post by Ron
Post by Ron
we couldn't get Jersey to use our class. We tried the
@Provider annotation and the web.xml config, but at no avail.
Post by Ron
Post by Ron
Once we our class to one of the specific RESTful projects,
it started working.
Post by Ron
Post by Ron
I'm trying to understand the cause for this. As far as I
can tell, there are two possible reasons: it's either the
Post by Ron
Post by Ron
way Jersey decides on which provider to use for a mime-type
(since there's now more than one provider for JSON -
Post by Ron
Post by Ron
Jackon's and our own) or it's a class-loading order issue
(which also may impact the first option).
Post by Ron
Post by Ron
Can anyone explain the process of how Jersey decides which
MBR to use for a content-type, and perhaps suggest a
Post by Ron
Post by Ron
saner solution? Right now it seems the only way to make it
work is duplicate the code (to an extent) in the
Post by Ron
Post by Ron
various API projects.
Thanks,
Ron
--
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com
Ron
2011-12-20 20:28:52 UTC
Permalink
Thanks guys for the support.

Unfortunately, I read your message only now (work day is long over here),
but one of my team developers did just that - added it to the
ResourceConfig and it works perfectly now.

All in all, it all worked out for the best, and I'm glad to have learned
how it should have been configured in the first place.

Regards,
Ron
Post by Jakub Podlesak
**
Hi Ron,
Application provided MBRs should always take precedence,
otherwise the ordering is not guaranteed by Jersey.
I.e. you would need to add your MBR class explicitly to your ResourceConfig
or Application class.
If you are not sure, could you please share your web.xml or
ResourceConfig/Application code,
so that i may suggest how to fix that?
Thanks,
~Jakub
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
Post by Marek Potociar
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
Post by Ron
All we did to solve the issue was to move the provider class from one
project to another, keeping it in the same package.
Post by Ron
The web.xml was already modified in the target project, so it must be
something else.
Post by Ron
On Mon, Dec 19, 2011 at 23:04, Farrukh Najmi <
__
When in a similar situation before I found that any number of very
easy mistakes can cause the detection of your
Post by Ron
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
Post by Ron
NetBeans debugger with compatible versions of jersey source to step
through the code and find out the really dumb
Post by Ron
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
Post by Ron
significant. What is significant from that experience is that I had
to debug the jersey code to understand what was
Post by Ron
wrong.
Post by Ron
Hi everyone,
We've tried implementing our own custom MessageBodyReader which is
based off on Jackson's JacksonJsonProvider.
annotation to accompany it.
Post by Ron
Post by Ron
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.
Post by Ron
Post by Ron
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.
Post by Ron
Post by Ron
Trying to get the application to recognize our custom
MessageBodyReader, it seemed that no matter what we tried,
annotation and the web.xml config, but at no avail.
Post by Ron
Post by Ron
Once we our class to one of the specific RESTful projects, it
started working.
Post by Ron
Post by Ron
I'm trying to understand the cause for this. As far as I can tell,
there are two possible reasons: it's either the
Post by Ron
Post by Ron
way Jersey decides on which provider to use for a mime-type (since
there's now more than one provider for JSON -
Post by Ron
Post by Ron
Jackon's and our own) or it's a class-loading order issue (which
also may impact the first option).
Post by Ron
Post by Ron
Can anyone explain the process of how Jersey decides which MBR to
use for a content-type, and perhaps suggest a
Post by Ron
Post by Ron
saner solution? Right now it seems the only way to make it work is
duplicate the code (to an extent) in the
Post by Ron
Post by Ron
various API projects.
Thanks,
Ron
--
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com
emiddio-frontier
2011-12-20 14:36:06 UTC
Permalink
was the web.xml version the same ?
----- Original Message -----
From: Ron
To: users-ywjJWXFEILO43ww/***@public.gmane.org
Sent: Monday, December 19, 2011 9:46 PM
Subject: [Jersey] Re: Custom MessageBodyReader


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-vQC+liUdx4ovD+***@public.gmane.org> 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
Loading...