Sergey, But I see this as a really simple thing to implement. If you've already got stuff in place to transform the submission of a POST into an object,, why not let a developer specify a parameter through annotations? Whether the XML is valid or not is not something we need to worry about - a client can submit broken XML via a POST or via an HTTP parameter. Ideally we want to be able to pass multiple objects to methods too!
public void method(MyObject a, MyOtherObject b); And annotate with the HTTP parameters to use when deserialising. This functionality would also make it easy to build test web interfaces, which was my original plan. No-one wants to type wget --post-file - they want to post XML into a text box in a browser window. John Baker -- Web SSO IT Infrastructure Deutsche Bank London URL: http://websso.cto.gt.intranet.db.com "Sergey Beryozkin" <[EMAIL PROTECTED]> 12/05/2008 16:48 Please respond to [email protected] To <[email protected]> cc <[email protected]> Subject Re: HTTP multipart/form-data and REST I don't see it as a viable approach for a *default* JAXB provider for a number of reasons : * The format of parameters can be arbitrary and there's no standard way to indicate that the value of a query parameter X is an instance of XML or comma-seperated entity, etc * Even though I've listed this option I'm not sure body readers, by definition, are good candidates for deserializing query params * Multiple parameters can have different formats, etc... Perhaps you may want to raise this issue at a JAX-RS users list and suggest introducing some sort of QueryProviders which will be called/given an opportunity by the runtime to deserialize a given complex query param.. Cheers, Sergey > Indeed, encoding is performed - I was just illustrating the concept > because the browser would encode the XML. > > I don't understand option 2 but I'm still not quite sure I've made my > point clear. CXF currently has no problems using JAXBElementProvider to > deserialise the contents of a POST, so why can't we make it work for an > HTTP parameter? Why is it so hard to implement some logic to say, "If > there's no parameters submitted then take the entire submission and > deserialise - as is already the case - but if there's name/value > parameters then use the value of parameter X and process with > JAXBElementProvider". > > Surely this could be achieved through option 1 without a specific valueOf > method - you have all the code! > > > John Baker > -- > Web SSO > IT Infrastructure > Deutsche Bank London > > URL: http://websso.cto.gt.intranet.db.com > > > > > "Sergey Beryozkin" <[EMAIL PROTECTED]> > 12/05/2008 13:28 > Please respond to > [email protected] > > > To > <[email protected]> > cc > <[email protected]> > Subject > Re: HTTP multipart/form-data and REST > > > > > > > Hi, > > >> http://localhost:8080/rest/push?X=<moo /> >> >> I want to build an interface where a user can paste XML into a web form >> and press submit. As opposed to doing wget --post-file test.xml >> http://localhost:8080/rest/push > > I'm not sure if XML can be pasted like that, perhaps some escaping will > need to be done, but either way, when dealing with complex query > parameters, perhaps two options are available : > > 1. Add a static valueOf(String s) method to MyObject : > > class MyObject { > public static MyObject valueOf(String xmlString) { > // convert that XML into an instance of MyObject somehow > } > > and then just do > > Response post(@QueryParam("X") MyObject o) {...} > > > 2. Have a custom MessageBodyReader for MyObject, in its readFrom() method > ignore the input stream, but instead deserialize the given query parameter > into MyObject. For this to work, an instance of JAX-RS UriInfo will need > to be injected into a custom reader's @Context-annotated field of type > UriInfo by the runtime, UriInfo will provide an access to query > parameters. CXF though does not support yet the injection of context > fields so at the tine being option1 would be the way to go. > > and then just do > > Response post(MyObject o) {...} > > > Cheers, Sergey > >> >> >> John Baker >> -- >> Web SSO >> IT Infrastructure >> Deutsche Bank London >> >> URL: http://websso.cto.gt.intranet.db.com >> >> >> >> >> "Sergey Beryozkin" <[EMAIL PROTECTED]> >> 12/05/2008 11:58 >> Please respond to >> [email protected] >> >> >> To >> <[email protected]> >> cc >> <[email protected]> >> Subject >> Re: HTTP multipart/form-data and REST >> >> >> >> >> >> >> I'm feeling so slow myself :-), it it because it's Monday ? >> >> >>> Hi, >>> >>> I'm talking about deserialising to an object - I've been looking at >>> JAXBElementProvider which I assume is the default provider for: >>> >>> public Response post(MyObject o); >> >> JAXBElementProvider is a default provider for serializing/deserilizing >> JAXB-annotated classes, when application/xml media type is >> used...On input, it will take the whole input body and attempt to >> deserialize it, on output it will take the response entity and >> serialize it into the provided output stream... >> >>> >>> and I want to submit the XML with the parameter 'X' and deserialise to >>> MyObject. >> >> I really don't understand it. Can you please elaborate on what does it >> mean to 'submit the XML with the parameter 'X'' ? >> >> Cheers, Sergey >> >>> >>> >>> John Baker >>> -- >>> Web SSO >>> IT Infrastructure >>> Deutsche Bank London >>> >>> URL: http://websso.cto.gt.intranet.db.com >>> >>> >>> >>> >>> "Sergey Beryozkin" <[EMAIL PROTECTED]> >>> 12/05/2008 11:34 >>> Please respond to >>> [email protected] >>> >>> >>> To >>> <[email protected]> >>> cc >>> <[email protected]> >>> Subject >>> Re: HTTP multipart/form-data and REST >>> >>> >>> >>> >>> >>> >>> Hi, >>> >>> >>>> 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!). >>> >>> thanks :-) >>> >>>> >>>> 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? >>> >>> Lets assume a request looks like this : >>> >>> POST /service?param1=1¶m2=2 >>> >>> <someXML/> >>> >>> When you say 'deserialise the value of parameter X', do you refer to >> query >>> parameters like 'param1' above ? >>> If yes then yiu just need to use @QueryParam : >>> >>> Response post(@QueryParam("param1") String p1) >>> >>> The query parameter param1 will be converted into a String or it can be >>> converted into other type like Long or Integer which have a >>> constructor accepting a string and/or valueOf(String) method... >>> >>> Or are you referring to deserializing some pieces from the <someXML/> >> body >>> ? You were talking about dealing with multipart/form-data >>> earlier, is it still the problem we're discussing here ? >>> >>> Cheers, Sergey >>> >>> >>>> >>>> >>>> John Baker >>>> -- >>>> Web SSO >>>> IT Infrastructure >>>> Deutsche Bank London >>>> >>>> URL: http://websso.cto.gt.intranet.db.com >>>> >>>> >>> >>> ---------------------------- >>> 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. ---------------------------- 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.
