On Jan 27, 2009, at 5:33 PM, James Strachan wrote:
> 2009/1/27 Craig McClanahan <Craig.McClanahan_at_sun.com>:
>> James Strachan wrote:
>>>
>>> I've been pondering this for a little while; is JAX-RS the kinda
>>> long
>>> term replacement for all the zillions of web frameworks out there?
>>>
>>> I tend to think, yes it mostly is for most requirements - and we're
>>> nearly there, just a few things to fix up and improve. I've just
>>> blogged (a rather long post for me) about it, brain dumping my
>>> thoughts
>>>
>>> http://macstrac.blogspot.com/2009/01/jax-rs-as-one-web-framework-to-rule.html
>>>
>>> it could well feed the trolls but it'd be interesting to hear if
>>> others have been having similar thoughts (or maybe I'm just smoking
>>> crack :).
>>
>> Having seen you party, I'm not sure I could tell the
>> difference ... :-)
>
> LOL! Hi Craig, long time no see! I nearly referred to you in that blog
> post using Hani's McClanahanahanahan but couldn't remember the correct
> spelling & repetition :)
>
>
>>> From seeing folks hit similar issues to me in the implicit
>>> views / static files /JSP mappings areas - it looks like at least a
>>> few folks are trying to do similar things.
>>>
>>
>> Perhaps ironically (given my background), I haven't paid a lot of
>> attention
>> to using Jersey for a webapp that produces server side HTML views.
>> That's
>> probably because nearly all my time nowdays is going towards REST
>> services
>> based Jersey, with a heavy dose of Jersey Client for the Java clients
>> (although I'm using Ruby/Python/PHP for that as well). But I think
>> there's
>> a lot of merit in your comments here.
>>
>> The biggest single issue (to me) is one you mentioned, and it's not
>> just a
>> JAX-RS issue. It's the problem of letting the container do its
>> thing for
>> static resources. You can work around this by ugly things like
>> different
>> context paths for the resources and the static files (or explicitly
>> map
>> every root resource "foo" to path "/foo/*" and remember to update
>> when you
>> add a new root resource), but it would really be nice if Servlet
>> 3.0 let us
>> do a more sophisticated mapping job.
>
> Agreed!
>
>
>> PS: Thanks for the props on jersey-multipart. What kind of thing
>> did you
>> have in mind for "direct binding with any bean"?
>
> I was just mentally joining the dots (without being very clear)
> between stuff you'd posted on the multipart thread; where you could
> bind directly to parameters to avoid using an explicit MultPart type
>
> e.g.
>
> @Path("...")
> @PUT
> @Consumes("multipart/mixed")
> @Produces(...)
> public void handler(String text, MyBean bean) {...}
>
> instead of
>
> public void handler(MultiPart multipart) {..
> BodyPart part0 = multiPart.getBodyParts().get(0);
> String text = part0.getEntityAs(String.class);
> BodyPart part1 = multiPart.getBodyParts().get(1);
> MyBean bean = part1.getEntityAs(MyBean.class);
> ...
> multiPart.cleanup();
> }
>
You can do that with @FormParam for multipart/form-data, the name of
the form parameter corresponds to the name in the content disposition
header. Craig has been working on transitioning over the
implementation of that to build upon the multipart API.
I would like to see beans being used, say:
@Multipart
public class MultipartBean {
// possible annotations on bean properties.
String text;
MyBean bean;
}
@POST
public void post(MultipartBean bean) { ... }
same applies to form parameter beans.
Paul.