Hi Sergey,
Thanks for the answer. I think I can explain better my issue. I wrote it
very quickly at work, looking forward to go home, and now I've seen some
mistakes in my explanation.
But I think it easier if you see this way:
I was doing a REST API with XML replies. So I use this annotations in my
bean:
@Produces("text/xml")
@Consumes("text/xml")
class MyService {.....}
But you can really reply whatever content you want. That annotations are
Content-Type headers issues. You even might reply binary data (sure, client
won't understand, but your bean will do the work you want).
Then I decided to use JSON replies, with Jettison (Implemented in
JSONProvider). And to be robust, I did this:
@ProduceMime({"text/json", "json/application"})
@ConsumeMime({"text/json", "json/application"})
class MyService {.....}
There is still lot of confusion about right MIME type for JSON. So my bean
can support both. But then I saw that it didn't work.
With "Accept: text/json" requests, the responses were still XML, and with
"json/aplication" were JSON. Why?. When I don't use JSONProvier and if I
reply an String with JSON it works with any content-type.
Then I copied JSONProvider class and I changed annotations:
@ProduceMime("*/*")
@CosumeMime("*/*")
Same as if you delete them.
And it works, my beans uses its annotations, not JSONProvider annotations.
The annotations I configured.
Seeing the problem I was looking a solution without library code
modifications.
One solution is to subclass JSONProvider, just to change the annotations,
but I couldn't subclass it, about the final (I suppose the final is right
here, it is only that I couldn't do what I wanted, "final" isn't the
problem).
Then the other solution is delegation, and it works, perfectly, without
library modifications, but requires more code.
I hope this explain my point of view.
Thanks,
Pedro
Hi Pedro
> But when you use JSONProvider you have to use "application/json" to
get
"JSON".
Yes, it's hardcoded at the moment
> I know it doesn't right not to use "application/json", but I think
that
should be developer decision.
Actually, I agree with you - whatever fits best the developer's
application is the right decision.
> public final class JSONProvider extends AbstractJAXBProvider { ... }
I'll fix it - I see no reason in it being final - I didn't even know it
was :-)
>@ProduceMime("text/plain" )
>public ContactEntry get() { ... }
>Produces XML because I'm using JAXB. (It isn't good using XML like
plain
Actually, I updated the JAXB provider to produce/consume either
application/xml or text/xml
> <bean id="jsonProvider"
class="org.apache.cxf.jaxrs.provider.JSONProvider"/>
json is supported by default so there's no need to explicitly register
it unless you need to configure a JSON provider or pass it to a
delegation handler as in your case.
Overall you raise an interesting question : how to extend providers to
support arbitrary mime types. I've seen this issue raised at the Jersey
list too.
I reckon we can address this issue similarly to the way you suggested.
We can start with JAXB and JSON ones and update other providers as
needed.
Basically, they can omit static Produces/Consumes definitions (which is
equivalent to using */* as their values) and have a list of mime types
supported by default instead.
So for ex, in case of JSON we'll have
@Provider
public class JSONProvider extends AbstractJAXBProvider {
protected List<MediaType> consumeTypes = ...
protected List<MediaType> produceTypes = ...
// will contain application/json at init
}
And have the setter method which will allow either append to or
overwrite this list from Spring.
Next, in isWriteable, isReadable we will match these values against the
Produces/Consumes on Class/Method
I need to think about it a bit more...
Thanks, Sergey
--
View this message in context:
http://www.nabble.com/Json-and-XML-%40ProduceMime-tp20549326p20741653.html
Sent from the cxf-user mailing list archive at Nabble.com.
