Thanks Paul,
Good advice -- I'll split the method out, and try the snapshot.
Regards,
Davis
On Mon, Nov 24, 2008 at 5:54 AM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
> Hi,
>
> I think i know what the issue is, apologies for the long time working it
> out, i was being dumb cause i forgot to include the Java mail dependency,
> thus could not reproduce, doh!
>
> I have committed a fix in the trunk.
>
> As a work around you could have separate methods for each media type:
>
> @POST
> @Produces("text/html")
> @Consumes("application/x-www-form-urlencoded")
> public String doPost(@FormParam("xml") String xml) { ... }
>
> @POST
> @Produces("text/html")
> @Consumes("multipart/form-data")
> public String doPost(@FormParam("xml") String xml) { ... }
>
> Note that when both media types are supported on the same method there are
> some different constraints in force than if they are separate, this is
> because it is hard to fully abstract the processing for the overloaded use
> of FormParam. The urlencoded is string based, where as form-data is binary
> based. I need to find time to document this carefully... currently i am what
> is referred to as time bankrupt!
>
> Paul.
>
> On Nov 21, 2008, at 7:47 PM, Davis Ford wrote:
>
>> I am still not quite out of the woods yet on this issue.
>>
>> I have the following:
>>
>> @POST
>> @Produces("text/html")
>> @Consumes({"application/x-www-form-urlencoded",
>> "multipart/form-data"})
>> public String doPost(@FormParam("xml") String xml) {
>>
>> and I am testing using HttpUnit. All my test cases pass fine if I
>> send the 'xml' parameter, but I have one test that does not, and it
>> causes the stack trace posted below:
>>
>> Using jersey-server 1.0.1-SNAPSHOT, and I did mvn refresh this morning.
>>
>> My test case in general does something like this:
>>
>> import com.meterware.httpunit.PostMethodWebRequest;
>> import com.meterware.httpunit.WebConversation;
>> import com.meterware.httpunit.WebResponse;
>>
>> PostMethodWebRequest req = new PostMethodWebRequest(URL);
>> WebConversation wc = new WebConversation();
>> WebResponse resp = wc.getResponse(req);
>>
>> In my other tests, I set the xml parameter in the req object like:
>>
>> req.setParameter("xml", StringUtil.readFileAsString(XML));
>>
>> Those tests pass as expected, but the test where I don't set the
>> parameter generates a NPE. I have confirmed that the content-type
>> that HttpUnit is sending is:
>> {Content-Type=application/x-www-form-urlencoded}.
>>
>> com.sun.jersey.api.container.ContainerException: Exception injecting
>> parameters to Web resource method
>> at
>> com.sun.jersey.server.impl.model.method.dispatch.FormDispatchProvider$FormParamInInvoker.getParams(FormDispatchProvider.java:99)
>> at
>> com.sun.jersey.server.impl.model.method.dispatch.FormDispatchProvider$TypeOutInvoker._dispatch(FormDispatchProvider.java:128)
>> at
>> com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:67)
>> at
>> com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:124)
>> at
>> com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:71)
>> at
>> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:111)
>> at
>> com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:63)
>> at
>> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:555)
>> at
>> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:514)
>> at
>> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:505)
>> at
>> com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:349)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
>> at
>> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502)
>> at
>> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:363)
>> at
>> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
>> at
>> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
>> at
>> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
>> at
>> org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:417)
>> at
>> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
>> at
>> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
>> at
>> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
>> at org.mortbay.jetty.Server.handle(Server.java:324)
>> at
>> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:534)
>> at
>> org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:864)
>> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:533)
>> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:207)
>> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:403)
>> at
>> org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
>> at
>> org.mortbay.jetty.security.SslSocketConnector$SslConnection.run(SslSocketConnector.java:636)
>> at
>> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:522)
>> Caused by: com.sun.jersey.api.container.ContainerException:
>> java.lang.NullPointerException
>> at
>> com.sun.jersey.server.impl.model.method.dispatch.MultipartFormDispatchProvider$MultipartFormParamInjectable.getValue(MultipartFormDispatchProvider.java:180)
>> at
>> com.sun.jersey.server.impl.model.method.dispatch.FormDispatchProvider$FormParamInInvoker.getParams(FormDispatchProvider.java:93)
>> ... 29 more
>> Caused by: java.lang.NullPointerException
>> at
>> com.sun.jersey.server.impl.model.method.dispatch.MultipartFormDispatchProvider$MultipartFormParamInjectable.getAsForm(MultipartFormDispatchProvider.java:195)
>> at
>> com.sun.jersey.server.impl.model.method.dispatch.MultipartFormDispatchProvider$MultipartFormParamInjectable.getValue(MultipartFormDispatchProvider.java:175)
>> ... 30 more
>>
>>
>> On Thu, Nov 20, 2008 at 10:23 AM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>>>
>>> On Nov 20, 2008, at 4:07 PM, Davis Ford wrote:
>>>
>>>> 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"})
>>>>
>>>
>>> How do you want to process the message if it is "application/xml" or
>>> "text/xml" and what response do you want to produce?
>>>
>>> @FormParam only makes sense for form-based media types.
>>>
>>> You can have another method that catches anything else:
>>>
>>> @POST
>>> // By default @Consumes("*")
>>> public void anythingElse() {
>>> }
>>>
>>> or you can let Jersey return a 415 client error.
>>>
>>>
>>>> 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.
>>>>
>>>
>>>
>>> https://jersey.dev.java.net/source/browse/*checkout*/jersey/trunk/jersey/dependencies.html
>>>
>>> Paul.
>>>
>>>> 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
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> 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