You are right, this bears some ambiguity. One could argue that JAXB is
mentioned in the spec while JSON is not, but that would confuse people.
I think for now it would be enough to just improve the phrasing of the
message, as it actually is clear that it is the user's fault to pass in
data without giving the content type. I will file a RFE for that.
Thanks
Markus
From: Jakub Podlesak [mailto:jakub.podlesak_at_oracle.com]
Sent: Freitag, 18. Februar 2011 11:26
To: users_at_jersey.java.net
Subject: [Jersey] Re: Doesn't find reader, but list it?
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$StreamSourceRead
er
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