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();
}
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/