Menu
▾
▴
resteasy-developers
|
From: Ryan J. M. <ry...@da...> - 2008-03-15 19:02:12
Attachments:
PGP.sig
|
In one of the initial versions of RESTEasy (some code I never
apparently committed) I did have a RepresentationHandler for
"multipart/form-data" and it worked out okay. The only down side was
your method ended up looking something like this:
@ConsumeMime("multipart/form-data")
public Object post(MimeMultipart muliPart) {
Order order =
MultipartHelper.unmarshallPart( mp.getBodyPart(0),Order.class);
...
Not the most elegant solution, but it should be able to work within
guidelines of JAX-RS. On the other hand, it maybe nice to do something
more like:
@ConsumeMime("multipart/form-data")
public Object post(@MultiPartParam(name="order",type = "application/
order+xml") Order order) {
...
In this case, we'd push all of the processing logic to RESTEasy and
the let the developer work with order element directly. However, I'm
not sure if the processing logic would conflict with JAX-RS. I'm
trying to play catch up on the spec as I got a bit rusty over the past
few months. The MessageReader/Writer stuff is a bit new to me.
I'm curious to hear any opinions.
Ryan- |
|
From: Bill B. <bb...@re...> - 2008-03-15 19:19:16
|
Ryan J. McDonough wrote:
> In one of the initial versions of RESTEasy (some code I never
> apparently committed) I did have a RepresentationHandler
> for "multipart/form-data" and it worked out okay. The only down side was
> your method ended up looking something like this:
>
Cool, port it over :)
> @ConsumeMime("multipart/form-data")
> public Object post(MimeMultipart muliPart) {
> Order order = MultipartHelper.unmarshallPart(
> mp.getBodyPart(0),Order.class);
> ...
>
> Not the most elegant solution, but it should be able to work within
> guidelines of JAX-RS. On the other hand, it maybe nice to do something
> more like:
>
Why do you
> @ConsumeMime("multipart/form-data")
> public Object post(@MultiPartParam(name="order",type =
> "application/order+xml") Order order) {
> ...
>
> In this case, we'd push all of the processing logic to RESTEasy and the
> let the developer work with order element directly. However, I'm not
> sure if the processing logic would conflict with JAX-RS. I'm trying to
> play catch up on the spec as I got a bit rusty over the past few months.
> The MessageReader/Writer stuff is a bit new to me.
>
I don't think it would work with JAX-RS. The problem is, there's no way
in isReadable() to determine what the mime type of Order is. You could
see @MultiPartParam within isReadable() as the signature now accepts
Annotation[], but you'd have to hope and pray that Order's type matches
something when you get into readFrom().
BTW, I was also hoping to support multipart/mixed, form-data with
List<>, and Set<> return and parameter types.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
|
|
From: Ryan J. M. <ry...@da...> - 2008-03-15 22:55:16
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I was just taking a look at one of you older threads regarding List<>
and Set<> and it shouldn't be that difficult to support. I'll start by
porting the original RepresentationHandler implementation and then
work on the List and Set idea.
Ryan-
On Mar 15, 2008, at 3:20 PM, Bill Burke wrote:
>
>
> Ryan J. McDonough wrote:
>> In one of the initial versions of RESTEasy (some code I never
>> apparently committed) I did have a RepresentationHandler for
>> "multipart/form-data" and it worked out okay. The only down side
>> was your method ended up looking something like this:
>
> Cool, port it over :)
>
>> @ConsumeMime("multipart/form-data")
>> public Object post(MimeMultipart muliPart) {
>> Order order =
>> MultipartHelper.unmarshallPart( mp.getBodyPart(0),Order.class);
>> ...
>> Not the most elegant solution, but it should be able to work within
>> guidelines of JAX-RS. On the other hand, it maybe nice to do
>> something more like:
>
> Why do you
>
>> @ConsumeMime("multipart/form-data")
>> public Object post(@MultiPartParam(name="order",type = "application/
>> order+xml") Order order) {
>> ...
>> In this case, we'd push all of the processing logic to RESTEasy and
>> the let the developer work with order element directly. However,
>> I'm not sure if the processing logic would conflict with JAX-RS.
>> I'm trying to play catch up on the spec as I got a bit rusty over
>> the past few months. The MessageReader/Writer stuff is a bit new to
>> me.
>
> I don't think it would work with JAX-RS. The problem is, there's no
> way in isReadable() to determine what the mime type of Order is.
> You could see @MultiPartParam within isReadable() as the signature
> now accepts Annotation[], but you'd have to hope and pray that
> Order's type matches something when you get into readFrom().
>
>
> BTW, I was also hoping to support multipart/mixed, form-data with
> List<>, and Set<> return and parameter types.
>
> Bill
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
iD8DBQFH3FPKK/xjmUY6JwURAvBpAKCHfd3wCUfYrjCuPDvhEkSA3K2SYgCfRU27
9jP/gcnxflhnEy/AC3Gzc/M=
=cEB/
-----END PGP SIGNATURE-----
|
|
From: Bill B. <bb...@re...> - 2008-03-17 12:34:25
|
I think prototyping/implementing Multipart input and output would
greatly help to flush out the spec too.
Ryan J. McDonough wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I was just taking a look at one of you older threads regarding List<>
> and Set<> and it shouldn't be that difficult to support. I'll start by
> porting the original RepresentationHandler implementation and then work
> on the List and Set idea.
>
> Ryan-
>
> On Mar 15, 2008, at 3:20 PM, Bill Burke wrote:
>
>>
>>
>> Ryan J. McDonough wrote:
>>> In one of the initial versions of RESTEasy (some code I never
>>> apparently committed) I did have a RepresentationHandler for
>>> "multipart/form-data" and it worked out okay. The only down side was
>>> your method ended up looking something like this:
>>
>> Cool, port it over :)
>>
>>> @ConsumeMime("multipart/form-data")
>>> public Object post(MimeMultipart muliPart) {
>>> Order order = MultipartHelper.unmarshallPart(
>>> mp.getBodyPart(0),Order.class);
>>> ...
>>> Not the most elegant solution, but it should be able to work within
>>> guidelines of JAX-RS. On the other hand, it maybe nice to do
>>> something more like:
>>
>> Why do you
>>
>>> @ConsumeMime("multipart/form-data")
>>> public Object post(@MultiPartParam(name="order",type =
>>> "application/order+xml") Order order) {
>>> ...
>>> In this case, we'd push all of the processing logic to RESTEasy and
>>> the let the developer work with order element directly. However, I'm
>>> not sure if the processing logic would conflict with JAX-RS. I'm
>>> trying to play catch up on the spec as I got a bit rusty over the
>>> past few months. The MessageReader/Writer stuff is a bit new to me.
>>
>> I don't think it would work with JAX-RS. The problem is, there's no
>> way in isReadable() to determine what the mime type of Order is. You
>> could see @MultiPartParam within isReadable() as the signature now
>> accepts Annotation[], but you'd have to hope and pray that Order's
>> type matches something when you get into readFrom().
>>
>>
>> BTW, I was also hoping to support multipart/mixed, form-data with
>> List<>, and Set<> return and parameter types.
>>
>> Bill
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (Darwin)
>
> iD8DBQFH3FPKK/xjmUY6JwURAvBpAKCHfd3wCUfYrjCuPDvhEkSA3K2SYgCfRU27
> 9jP/gcnxflhnEy/AC3Gzc/M=
> =cEB/
> -----END PGP SIGNATURE-----
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
|
Thanks for helping keep SourceForge clean.
X