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.
