resteasy-developers — The main list for RESTEasy developers to discuss project development

Re: [Resteasy-developers] Thoughts on a MultipartProvider

[Bill B. <bb...@re...>]

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

Re: [Resteasy-developers] Synced with jsr311 trunk

[Bill B. <bb...@re...>]

That would be cool and most helpful.  Multipart definitely needs this. 
Timeframe?  I want to get out another release in 2 weeks or so as I have 
  another resteasy project dependent on the next release.

Ryan J. McDonough wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> You mean things like MessageBodyWorkers? I just want to clarify that 
> this is the interface that is used to lookup and different providers for 
> MessageBodyReader/Writer's? If you haven't started on this already, I'd 
> be interested in taking a stab at this one. For the 
> MimeMultipartProvider, I'd like to try and leverage existing providers 
> for the message parts and having access to the look up mechanism would 
> be handy.
> 
> Ryan-
> 
> 
> On Mar 15, 2008, at 3:22 PM, Bill Burke wrote:
> 
>> FYI, on Friday, I synced up with JSR311 trunk.  There's some cool stuff
>> going on there that I want to take advantage of.
>>
>> -- 
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Resteasy-developers mailing list
>> Res...@li...
>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (Darwin)
> 
> iD8DBQFH3Qy/K/xjmUY6JwURAmtcAJ4w0DH+zHOr87FbNmy8j/biB//gDgCgmYFB
> AMvH/Xjci5i0GbHdElpCyBM=
> =yLv5
> -----END PGP SIGNATURE-----

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

Re: [Resteasy-developers] JBoss Remoting for RESTEasy?

[Bill B. <bb...@re...>]

I think I'd rather check out Apache MINA and/or Grizzly first.  JBoss 
Remoting wasn't too focused on HTTP performance.  I tried to keep the 
servlet adapter as separated as possible from the rest of RESTEasy.  It 
probably needs another round of refactoring.  Adapting a different, 
smaller HTTP engine might be the way to jumpstart this refactoring.

I used TJWS because its the only API I could find that had a programatic 
way to register servlets without having to create a WAR.  There are some 
problems with it, like it doesn't handle chunking very well  and you 
have to kill keep alive our the whole server gets fucked up.  I have 
talked to the creator about this, but I don't know if he's fixed the 
problems yet.

I'm more interested in REST over WebDav and REST over SMTP/POP/IMAP than 
REST over RMI.  REST over RMI sounds like an oxymoron.

Ryan J. McDonough wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Here's just another random thought as I am getting back into this:
> 
> Part of JAX-RS spec allows you the ability to run this stand alone. I  
> see that you have done some work with the Acme.Serve, but I wonder if  
> JBoss Remoting for a stand alone option? It would be pretty easy to  
> adapt JAX-RS to JBoss Remoting and from there it's another small step  
> to using the servlet adapter so we wouldn't have to reinvent the wheel  
> going forward. Some other benefits of JBoss Remoting would be being  
> able to take advantage of JBoss Serialization, multicast, etc..  Down  
> the road, we could do "REST over RMI", or other transports. While JAX- 
> RS is limited to HTTP, RESTEasy does not have to be. Curious to hear  
> any opinions.
> 
> Ryan-
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (Darwin)
> 
> iD8DBQFH3W+SK/xjmUY6JwURAiJ/AJ9as2aez+uXwavqygWXR4RHlFg2RgCgo5eM
> vKFn/YnfclKcUEsQO7yBYRk=
> =u3aq
> -----END PGP SIGNATURE-----
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

[Resteasy-developers] JBoss Remoting for RESTEasy?

[Ryan J. M. <ry...@da...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Here's just another random thought as I am getting back into this:

Part of JAX-RS spec allows you the ability to run this stand alone. I  
see that you have done some work with the Acme.Serve, but I wonder if  
JBoss Remoting for a stand alone option? It would be pretty easy to  
adapt JAX-RS to JBoss Remoting and from there it's another small step  
to using the servlet adapter so we wouldn't have to reinvent the wheel  
going forward. Some other benefits of JBoss Remoting would be being  
able to take advantage of JBoss Serialization, multicast, etc..  Down  
the road, we could do "REST over RMI", or other transports. While JAX- 
RS is limited to HTTP, RESTEasy does not have to be. Curious to hear  
any opinions.

Ryan-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFH3W+SK/xjmUY6JwURAiJ/AJ9as2aez+uXwavqygWXR4RHlFg2RgCgo5eM
vKFn/YnfclKcUEsQO7yBYRk=
=u3aq
-----END PGP SIGNATURE-----

Re: [Resteasy-developers] Synced with jsr311 trunk

[Ryan J. M. <ry...@da...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

You mean things like MessageBodyWorkers? I just want to clarify that  
this is the interface that is used to lookup and different providers  
for MessageBodyReader/Writer's? If you haven't started on this  
already, I'd be interested in taking a stab at this one. For the  
MimeMultipartProvider, I'd like to try and leverage existing providers  
for the message parts and having access to the look up mechanism would  
be handy.

Ryan-


On Mar 15, 2008, at 3:22 PM, Bill Burke wrote:

> FYI, on Friday, I synced up with JSR311 trunk.  There's some cool  
> stuff
> going on there that I want to take advantage of.
>
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFH3Qy/K/xjmUY6JwURAmtcAJ4w0DH+zHOr87FbNmy8j/biB//gDgCgmYFB
AMvH/Xjci5i0GbHdElpCyBM=
=yLv5
-----END PGP SIGNATURE-----

Re: [Resteasy-developers] Thoughts on a MultipartProvider

[Ryan J. M. <ry...@da...>]

-----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-----

[Resteasy-developers] Synced with jsr311 trunk

[Bill B. <bb...@re...>]

FYI, on Friday, I synced up with JSR311 trunk.  There's some cool stuff 
going on there that I want to take advantage of.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

Re: [Resteasy-developers] Thoughts on a MultipartProvider

[Bill B. <bb...@re...>]

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

[Resteasy-developers] Thoughts on a MultipartProvider

[Ryan J. M. <ry...@da...>]

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-

[Resteasy-developers] Testing 1 2 3

[Bill B. <bb...@re...>]

Yo.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

[Resteasy-developers] Testing

[Ryan M. <rmc...@sa...>]

Ryan J. McDonough
Platform, Specialist Java EE | Sapient
25 First Street
Cambridge, MA 02141
desk:  +1 617 761 1611
mobile: +1 508 735 4503
fax: +1 617 621 1300


The information transmitted is intended only for the person or entity  
to which it is addressed and may contain confidential and/or  
privileged material. Any review, retransmission, dissemination or  
other use of, or taking of any action in reliance upon, this  
information by persons or entities other than the intended recipient  
is prohibited. If you received this in error, please contact the  
sender and delete the material from any computer.