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
