2009/1/27 Paul Sandoz <Paul.Sandoz_at_sun.com>:
>
> 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.
Thats neat! :)
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/