Sergey, Thanks for updating the docs and there's no need to apologise for a delay in responding (in reference to another mail you sent) - your rapid feedback on responses is most welcome to those of us in a corporate world trying to demonstrate that open source is often better than close (BEA have a lot to learn!).
So consider my example - I'd like to deserialise the value of parameter X, instead of deserialising the body of the POST. How do I go about this? I appreciate I need to write a message body reader bu what does the deserializing? John Baker -- Web SSO IT Infrastructure Deutsche Bank London URL: http://websso.cto.gt.intranet.db.com "Sergey Beryozkin" <[EMAIL PROTECTED]> 12/05/2008 10:33 Please respond to [email protected] To <[email protected]> cc <[email protected]> Subject Re: HTTP multipart/form-data and REST Hi John I've updated the docs a bit, with more info about JAX-RS and custom providers in particular, have a look please http://cwiki.apache.org/CXF20DOC/jax-rs-jsr-311.html > > What object(s) currently deal with a straight POST submission and convert > into the required object? And how would I change this particular object > for a given post submission? Perhaps I can simply extend it and add the > code to deal with multipart? It is message body readers that affect the way a request input stream is converted into a given parameter type in a method. JAX-RS mandates the support for some types like String, etc. If your application needs to support a different type or it needs to override the way one of the default types is dealt with by the runtime then creating a custom message body reader is the way to go. Cheers, Sergey > > John Baker > -- > Web SSO > IT Infrastructure > Deutsche Bank London > > URL: http://websso.cto.gt.intranet.db.com > > > > > "Sergey Beryozkin" <[EMAIL PROTECTED]> > 08/05/2008 16:18 > Please respond to > [email protected] > > > To > <[email protected]> > cc > <[email protected]> > Subject > Re: HTTP multipart/form-data and REST > > > > > > > Hi, > > My understanding is that one would typically use MultivaluedMap to handle > HTML form submissions. > I don't think you can use MultivaluedMap for this kind of conversion. > > MessageBodyReaders implement readFrom() method. So if you would not like > the application code be aware of multipart/form-encoded > then you'd need to have a custom MessageBodyReader registered which will > do the conversion from a multipart/form-data into the type > expected by the application code. > DataSource may make it easier tp deal with multipart/* requests, but CXF > does not support it yet... > > Cheers, Sergey > > ----- Original Message ----- > From: "John-M Baker" <[EMAIL PROTECTED]> > To: <[email protected]> > Cc: <[email protected]> > Sent: Thursday, May 08, 2008 2:57 PM > Subject: Re: HTTP multipart/form-data and REST > > >> Sergey, >> >> Sure, I'll raise a ticket when I get a moment. But can you explain to > me >> how I submit a parameter ('xml') and get an object, not the XML, from > the >> map? >> >> Thanks, >> >> >> John Baker >> -- >> Web SSO >> IT Infrastructure >> Deutsche Bank London >> >> URL: http://websso.cto.gt.intranet.db.com >> >> >> >> >> "Sergey Beryozkin" <[EMAIL PROTECTED]> >> 08/05/2008 12:33 >> Please respond to >> [email protected] >> >> >> To >> <[email protected]> >> cc >> >> Subject >> Re: HTTP multipart/form-data and REST >> >> >> >> >> >> >> Hi >> >>> Response updateApplicationConfiguration(MultivaluedMap<String,String> >>> params); >> >> This actually should work... >> Perhaps you can do >> >> Response updateApplicationConfiguration(MetadataMap<String,String> >> params); >> >> MetadataMap is the CXF implementation of MultivaluedMap interface... >> The original signature should also work but I can't tell at the moment >> whether the bug is in the actual message reader or in the >> runtime code...Please open a JIRA to track this issue... >> >> Cheers, Sergey >> >> ----- Original Message ----- >> From: "John-M Baker" <[EMAIL PROTECTED]> >> To: <[email protected]> >> Sent: Thursday, May 08, 2008 9:15 AM >> Subject: Re: HTTP multipart/form-data and REST >> >> >>> My mistake, I meant to say: >>> >>> @POST >>> @PUT >>> @Path("/push/") >>> @ConsumeMime("application/x-www-form-urlencoded") >>> Response updateApplicationConfiguration(MultivaluedMap<String,String> >>> params); >>> >>> However this results in: >>> >>> javax.ws.rs.core.MultivaluedMap does not have a no-arg default >>> constructor. >>> this problem is related to the following location: >>> at javax.ws.rs.core.MultivaluedMap >>> at private javax.ws.rs.core.MultivaluedMap >>> com.db.websso.rest.server.jaxws_asm.UpdateApplicationConfiguration.arg0 >>> at > com.db.websso.rest.server.jaxws_asm.UpdateApplicationConfiguration >>> >>> Thoughts? >>> >>> >>> John Baker >>> -- >>> Web SSO >>> IT Infrastructure >>> Deutsche Bank London >>> >>> URL: http://websso.cto.gt.intranet.db.com >>> >>> >>> >>> >>> John-M Baker <[EMAIL PROTECTED]> >>> 08/05/2008 08:53 >>> Please respond to >>> [email protected] >>> >>> >>> To >>> [email protected] >>> cc >>> [email protected] >>> Subject >>> Re: HTTP multipart/form-data and REST >>> >>> >>> >>> >>> >>> >>> Sergey, >>> >>> I've been looking at the formEncodingReaderProvider that was included > in >>> CXF2.1. Perhaps if I change the use case a little I can understand how >> a >>> message provider exists within CXF. >>> >>> Given this example: >>> >>> @POST >>> @PUT >>> @Path("/push/") >>> @ConsumeMime("application/x-www-form-urlencoded") >>> public Response addX(Map<String, String> params); >>> >>> Does this automatically invoke the message producer? >>> >>> If I were to submit some XML with the parameter 'xml', is there a way > to >>> convert this into the object as would have happened if I'd done this: >>> >>> @POST >>> @Path("/push/") >>> public Response addX(MyBean bean); >>> >>> I can not see the point of a form encoding reader if the output is not > a >>> bean? >>> >>> >>> John Baker >>> -- >>> Web SSO >>> IT Infrastructure >>> Deutsche Bank London >>> >>> URL: http://websso.cto.gt.intranet.db.com >>> >>> >>> >>> >>> "Sergey Beryozkin" <[EMAIL PROTECTED]> >>> 07/05/2008 17:09 >>> Please respond to >>> [email protected] >>> >>> >>> To >>> <[email protected]> >>> cc >>> >>> Subject >>> Re: HTTP multipart/form-data and REST >>> >>> >>> >>> >>> >>> >>> In fact, you might get it working by having a method with the >> InputStream >>> input parameter (or may be even byte[]) and >>> ConsumeMime("multipart/form-data") and then process the >>> multipart/form-data directly in the method. >>> >>> Cheers, Sergey >>> >>> ----- Original Message ----- >>> From: "Sergey Beryozkin" <[EMAIL PROTECTED]> >>> To: <[email protected]> >>> Sent: Wednesday, May 07, 2008 4:49 PM >>> Subject: Re: HTTP multipart/form-data and REST >>> >>> >>> Hi >>> >>> JAX-RS mandates the support for DataSource and I reckon this would be >> the >>> way to get the multipart/form-data >>> in. CXF JAX-RS does not support this type yet. >>> >>> Possibly another viable alternative is to have a custom >> MessageBodyReader >>> which will have a ConsumeMime("multipart/form-data") annontation and >> then >>> in its readFrom() method it will transform the multipart/form-data >>> formatted input body into an appropriate type, as required by the > method >>> parameter... >>> >>> Cheers, Sergey >>> >>>> Hello, >>>> >>>> Using the CXFServlet and REST, wget can be used to post a file to a > URL >>>> defined as a post operation: >>>> >>>> wget --post-file file.xml url >>>> >>>> And wget makes the following HTTP submission: >>>> >>>> $ nc -p 1234 -l >>>> POST /blah/push HTTP/1.0 >>>> User-Agent: Wget/1.10.2 >>>> Accept: */* >>>> Host: localhost:1234 >>>> Connection: Keep-Alive >>>> Content-Type: application/x-www-form-urlencoded >>>> Content-Length: 599 >>>> >>>> <?xml version="1.0" encoding="UTF-8"?> >>>> <myxml> ... >>>> >>>> Is it possible to replicate this with a browser file submission? Or >>>> rather, is it possible for a POST operation to be defined so the data >> is >>> >>> >>>> taken from an HTTP parameter name? The browser submits a file as >>>> multipart/form-data but this does not appear to work when submitting > to >>> a >>>> URL that would otherwise handle a wget file post. >>>> >>>> Thanks, >>>> >>>> >>>> John Baker >>>> -- >>>> Web SSO >>>> IT Infrastructure >>>> Deutsche Bank London >>>> >>>> URL: http://websso.cto.gt.intranet.db.com >>>> >>>> >>>> --- >>>> >>>> This e-mail may contain confidential and/or privileged information. If >>> you are not the intended recipient (or have received this e-mail in >> error) >>> >>> please notify the sender immediately and delete this e-mail. Any >>> unauthorized copying, disclosure or distribution of the material in > this >>> e-mail is strictly forbidden. >>>> >>>> Please refer to http://www.db.com/en/content/eu_disclosures.htm for >>> additional EU corporate and regulatory disclosures. >>> >>> ---------------------------- >>> IONA Technologies PLC (registered in Ireland) >>> Registered Number: 171387 >>> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, >> Ireland >>> >>> ---------------------------- >>> IONA Technologies PLC (registered in Ireland) >>> Registered Number: 171387 >>> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, >> Ireland >>> >>> >>> >>> --- >>> >>> This e-mail may contain confidential and/or privileged information. If >> you >>> are not the intended recipient (or have received this e-mail in error) >>> please notify the sender immediately and delete this e-mail. Any >>> unauthorized copying, disclosure or distribution of the material in > this >>> e-mail is strictly forbidden. >>> >>> Please refer to http://www.db.com/en/content/eu_disclosures.htm for >>> additional EU corporate and regulatory disclosures. >>> >>> >>> --- >>> >>> This e-mail may contain confidential and/or privileged information. If >> you are not the intended recipient (or have received this >>> e-mail in error) please notify the sender immediately and delete this >> e-mail. Any unauthorized copying, disclosure or distribution >>> of the material in this e-mail is strictly forbidden. >>> >>> Please refer to http://www.db.com/en/content/eu_disclosures.htm for >> additional EU corporate and regulatory disclosures. >> >> ---------------------------- >> IONA Technologies PLC (registered in Ireland) >> Registered Number: 171387 >> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, > Ireland >> >> >> >> --- >> >> This e-mail may contain confidential and/or privileged information. If > you are not the intended recipient (or have received this >> e-mail in error) please notify the sender immediately and delete this > e-mail. Any unauthorized copying, disclosure or distribution >> of the material in this e-mail is strictly forbidden. >> >> Please refer to http://www.db.com/en/content/eu_disclosures.htm for > additional EU corporate and regulatory disclosures. > > ---------------------------- > IONA Technologies PLC (registered in Ireland) > Registered Number: 171387 > Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland > > > > --- > > This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this > e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution > of the material in this e-mail is strictly forbidden. > > Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. ---------------------------- IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures.
