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 ... :-)
> 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.
Craig
PS: Thanks for the props on jersey-multipart. What kind of thing did
you have in mind for "direct binding with any bean"?
> Thoughts?
>
>