Hi,
the requested behavior would definitely bring ambiguity
into the processing. There is for instance another JSON message body
provider
capable of processing @XmlRootElement annotated classes.
Which one should be used? The first one found?
As you wrote, unless you explicitly specify the content-type
header, it is hard to process such a request.
On the other hand, i understand that there might be cases,
where there is just one "suitable" worker and
in this case could be fine to use it.
Also for future Jersey versions i think we should
improve the whole process of registering
message body workers in Jersey. Now, you can easily end up
with a "wrong" provider just by dropping a 3rd party jar
into the classpath.
Then we can also introduce a resource configuration feature, which could
release/tweak the msg body workers selection criteria.
Could you please file a RFE on this?
Thanks,
~Jakub
On 02/18/2011 11:11 AM, Markus Karg wrote:
>
> Pavel,
>
> first, I do not have "application/octet-stream", but no type at all.
>
> Second, what negative impact do you actually assume? I mean, as long
> as custom providers have precedence, I cannot see why being able to
> process more input would actually be a fault?
>
> Regards
>
> Markus
>
> *From:*Pavel Bucek [mailto:pavel.bucek_at_oracle.com]
> *Sent:* Freitag, 18. Februar 2011 11:03
> *To:* users_at_jersey.java.net
> *Subject:* [Jersey] Re: Doesn't find reader, but list it?
>
> Hello Markus,
>
> XmlRootElementProvider$General has following "restriction":
>
> @Override
> protected boolean isSupported(MediaType m) {
> return m.getSubtype().endsWith("+xml");
> }
>
> and you have mediatype "application/octet-stream"..
>
> question here is why its restricted.. from message related to commit
> which introduced it (btw its from 11/28/08) I can see that Paul was
> extending possibilities for custom MessageBodyReaders/Writers, BUT
> afaik this has been refactored some time ago (user declared
> readers/writers have priority now) so we "might" get rid of it. On the
> other side.. I don't think its good idea, we should keep this
> backwards compatible, I can imagine that lots of apps could break
> after that change..
>
> Regards,
> Pavel
>
> On 2/18/11 10:51 AM, Markus Karg wrote:
>
> I am a bit confused about an error message in Jersey 1.4.
>
> I am PUTting a XML into a method that is marked as @Consumes(<some
> custom mime type>). The content variable is marked as XMLRootElement.
> As I forgot to provide the Content-Type header with the PUT, it is
> clear that Jersey complains about my fault, but what confuses me is
> the error message's explanation. Below you can see the (correct)
> complaint, but look down to the list of registered providers for ANY
> (*/*) content type. It does contain XMLRootElementProvider. So I
> understand that even with no mime provided, Jersey would be able to
> find that provider, but it actually does not use it...?
>
> Can someone shed some light on that? I understand what my fault is, I
> just don't understand why Jersey lists XMLRootElementProvider for */*
> but doesn't actually use it in this case.
>
> SCHWERWIEGEND: A message body reader for Java class
> de.quipsy.entities.ControlPlan, and Java type class
> de.quipsy.entities.ControlPlan, and MIME media type
> application/octet-stream was not found
>
> 18.02.2011 10:39:00 com.sun.jersey.spi.container.ContainerRequest
> getEntity
>
> SCHWERWIEGEND: The registered message body readers compatible with the
> MIME media type are:
>
> application/octet-stream ->
>
> com.sun.jersey.core.impl.provider.entity.ByteArrayProvider
>
> com.sun.jersey.core.impl.provider.entity.FileProvider
>
> com.sun.jersey.core.impl.provider.entity.InputStreamProvider
>
> com.sun.jersey.core.impl.provider.entity.DataSourceProvider
>
> com.sun.jersey.core.impl.provider.entity.RenderedImageProvider
>
> */* ->
>
> com.sun.jersey.core.impl.provider.entity.FormProvider
>
> com.sun.jersey.core.impl.provider.entity.MimeMultipartProvider
>
> com.sun.jersey.core.impl.provider.entity.StringProvider
>
> com.sun.jersey.core.impl.provider.entity.ByteArrayProvider
>
> com.sun.jersey.core.impl.provider.entity.FileProvider
>
> com.sun.jersey.core.impl.provider.entity.InputStreamProvider
>
> com.sun.jersey.core.impl.provider.entity.DataSourceProvider
>
> com.sun.jersey.core.impl.provider.entity.XMLJAXBElementProvider$General
>
> com.sun.jersey.core.impl.provider.entity.ReaderProvider
>
> com.sun.jersey.core.impl.provider.entity.DocumentProvider
>
>
> com.sun.jersey.core.impl.provider.entity.SourceProvider$StreamSourceReader
>
> com.sun.jersey.core.impl.provider.entity.SourceProvider$SAXSourceReader
>
> com.sun.jersey.core.impl.provider.entity.SourceProvider$DOMSourceReader
>
> com.sun.jersey.json.impl.provider.entity.JSONJAXBElementProvider$General
>
>
> com.sun.jersey.core.impl.provider.entity.*XMLRootElementProvider*$General
>
> com.sun.jersey.core.impl.provider.entity.XMLListElementProvider$General
>
> com.sun.jersey.core.impl.provider.entity.XMLRootObjectProvider$General
>
> com.sun.jersey.core.impl.provider.entity.EntityHolderReader
>
> com.sun.jersey.json.impl.provider.entity.JSONRootElementProvider$General
>
> com.sun.jersey.json.impl.provider.entity.JSONListElementProvider$General
>