FYI, even though semantically this may not make sense in the
traditional HTTP header sense, it achieves the catch-all I was looking
for (if the POSTer is really sending Content-Type:application/xml or
text/xml), and makes the NPE go away:
@Consumes({"application/x-www-form-urlencoded", "application/xml", "text/xml"})
One other brief question...there are a lot of different jars in the maven repo:
http://download.java.net/maven/2/com/sun/jersey/
Is it documented somewhere what the different projects consist of?
Granted you can use your intuition on the finely crafted naming
strategy, but I was just curious for future reference.
I am pulling in the 1.0.1-SNAPSHOT of jersey-core and jersey-server.
On Thu, Nov 20, 2008 at 9:42 AM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
> On Nov 20, 2008, at 3:15 PM, Davis Ford wrote:
>
>> Hi Paul,
>>
>> I can confirm the problem continues to exist for 1.0 and
>> 1.0.1-SNAPSHOT. However, if I change the annotation as you were
>> suspect of, the NPE goes away:
>>
>> @POST
>> @Produces("text/html")
>> // @Consumes({"application/x-www-form-urlencoded", "*/xml"})
>> @Consumes("application/x-www-form-urlencoded")
>>
>
> Also "*/xml" is a little odd, it is not really a valid wild card media type,
> where as "text/*" is. You can only have "*", "foo/*" or "foo/bar".
>
>
>> As to why I had this way...well, this is an integration between this
>> organization I am contracting for and another outside party. I have
>> tried to get confirmation from them on the HTTP header and what
>> content-type will consist of. The only information I received was
>> that it would be text/xml...although the content will come in a POST
>> via a parameter like:
>>
>> xml=<?xml version="1.0"?><InboundPostRequest>etc.....
>>
>
> Then the content type should still be "application/x-www-form-urlencoded",
> even if the value is of the xml parameter is a string that is an XML
> document.
>
> I think that is the issue in that the @FormParam only works with
> "application/x-www-form-urlencoded" and "multipart/form-data", so when
> content is consumed that is of another media type confusion arises.
>
> Obviously i could improve the errors/warnings around all this.
>
>
>> I would have assumed it would be x-www-form-urlencoded...but I have
>> yet to do a real test with them. Therefore, I added the catch-all
>> content-type for */xml in my unit tests, etc. In any event, NPE is
>> not quite what I expected.
>>
>
> Note that a 415 should be returned if the content type is not supported for
> consumption.
>
>
>> Thanks for your help. I have to just briefly say that building
>> restful services via JAX-RS is truly a delight and I am really liking
>> Jersey. Keep up the good work.
>>
>
> Thanks!
> Paul.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>
--
Zeno Consulting, Inc.
http://www.zenoconsulting.biz
248.894.4922 phone
313.884.2977 fax