JAX-RS / Jersey as the main Java web framework going forward...

[jstrachan]

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 :). 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.

Thoughts?

--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://fusesource.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[António Mota]

Well, it occurs to me that both JAX-RS and Jersey dosen't define client-side API's (however, other JAX-RS based frameworks do, like Restlet and RestEasy, if I'm not mistaken....)

So to build a full Web app you have to use Jersey *and* something else...

(i'm reading your blog post by pieces, i must say...)



On Jan 27, 2009 3:45pm, James Strachan <[hidden email]> 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 :). 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.
>
>
>
> Thoughts?
>
>
>
> --
>
> James
>
> -------
>
> http://macstrac.blogspot.com/
>
>
>
> Open Source Integration
>
> http://fusesource.com/
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: [hidden email]
>
> For additional commands, e-mail: [hidden email]
>
>
>

[Craig McClanahan]

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


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Craig McClanahan]

[hidden email] wrote:
> Well, it occurs to me that both JAX-RS and Jersey dosen't define
> client-side API's (however, other JAX-RS based frameworks do, like
> Restlet and RestEasy, if I'm not mistaken....)
>
> So to build a full Web app you have to use Jersey *and* something else...
>
> (i'm reading your blog post by pieces, i must say...)
>
JAX-RS does not currently define any standard client side API, but
Jersey most definitely does  And it works really well -- letting you
share the provider machinery from the server side.  You can start with
the Javadocs[1], read examples on Paul's blog[2], or look at nearly all
the unit tests for jersey-server -- they use jersey-client to exercise
the server side features.

[1]
https://jersey.dev.java.net/source/browse/*checkout*/jersey/tags/jersey-1.0.1/api/jersey/index.html
[2] http://blogs.sun.com/sandoz/category/REST

Craig

>
>
> On Jan 27, 2009 3:45pm, James Strachan <[hidden email]> 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 :). 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.
> >
> >
> >
> > Thoughts?
> >
> >
> >
> > --
> >
> > James
> >
> > -------
> >
> > http://macstrac.blogspot.com/
> >
> >
> >
> > Open Source Integration
> >
> > http://fusesource.com/
> >
> >
> >
> > ---------------------------------------------------------------------
> >
> > To unsubscribe, e-mail: [hidden email]
> >
> > For additional commands, e-mail: [hidden email]
> >
> >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[jstrachan]

2009/1/27  <[hidden email]>:
> Well, it occurs to me that both JAX-RS and Jersey dosen't define client-side
> API's (however, other JAX-RS based frameworks do, like Restlet and RestEasy,
> if I'm not mistaken....)

Jersey has a great client API - but you're right that its not yet part
of the JAX-RS standard.

>
> So to build a full Web app you have to use Jersey *and* something else...
>
> (i'm reading your blog post by pieces, i must say...)

Sorry its so long :)

--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://fusesource.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[jstrachan]

2009/1/27 Craig McClanahan <[hidden email]>:

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

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[António Mota]

I really didn't knew about the Jersey client... I wish I only had the time to look into it...

:-(


On Jan 27, 2009 4:24pm, James Strachan <[hidden email]> wrote:

> 2009/1/27  [hidden email]>:
>
> > Well, it occurs to me that both JAX-RS and Jersey dosen't define client-side
>
> > API's (however, other JAX-RS based frameworks do, like Restlet and RestEasy,
>
> > if I'm not mistaken....)
>
>
>
> Jersey has a great client API - but you're right that its not yet part
>
> of the JAX-RS standard.
>
>
>
> >
>
> > So to build a full Web app you have to use Jersey *and* something else...
>
> >
>
> > (i'm reading your blog post by pieces, i must say...)
>
>
>
> Sorry its so long :)
>
>
>
> --
>
> James
>
> -------
>
> http://macstrac.blogspot.com/
>
>
>
> Open Source Integration
>
> http://fusesource.com/
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: [hidden email]
>
> For additional commands, e-mail: [hidden email]
>
>
>

[Paul Sandoz]

On Jan 27, 2009, at 5:33 PM, James Strachan wrote:

> 2009/1/27 Craig McClanahan <[hidden email]>:
>> 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.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[jstrachan]

2009/1/27 Paul Sandoz <[hidden email]>:

>
> On Jan 27, 2009, at 5:33 PM, James Strachan wrote:
>
>> 2009/1/27 Craig McClanahan <[hidden email]>:
>>>
>>> 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/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Arul Dhesiaseelan]

It would be nice if JAX-RS defined a standard client-side API.
Currently, every implementation (Jersey, Resteasy, Restlet) provide
their own client APIs and it becomes cumbersome for tools to interface
with different implementations and had to use specific client APIs when
working with their resources. HTTP Client API is one option, but they
are not modeled around the resources which the Jersey client API does it
wisely.

Any plans to provide a standard client API which can interoperate with
various JAX-RS implementations?

-Arul

Craig McClanahan wrote:

> [hidden email] wrote:
>> Well, it occurs to me that both JAX-RS and Jersey dosen't define
>> client-side API's (however, other JAX-RS based frameworks do, like
>> Restlet and RestEasy, if I'm not mistaken....)
>>
>> So to build a full Web app you have to use Jersey *and* something
>> else...
>>
>> (i'm reading your blog post by pieces, i must say...)
>>
> JAX-RS does not currently define any standard client side API, but
> Jersey most definitely does  And it works really well -- letting you
> share the provider machinery from the server side.  You can start with
> the Javadocs[1], read examples on Paul's blog[2], or look at nearly
> all the unit tests for jersey-server -- they use jersey-client to
> exercise the server side features.
>
> [1]
> https://jersey.dev.java.net/source/browse/*checkout*/jersey/tags/jersey-1.0.1/api/jersey/index.html 
>
> [2] http://blogs.sun.com/sandoz/category/REST
>
> Craig
>>
>>
>> On Jan 27, 2009 3:45pm, James Strachan <[hidden email]> 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 :). 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.
>> >
>> >
>> >
>> > Thoughts?
>> >
>> >
>> >
>> > --
>> >
>> > James
>> >
>> > -------
>> >
>> > http://macstrac.blogspot.com/
>> >
>> >
>> >
>> > Open Source Integration
>> >
>> > http://fusesource.com/
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> >
>> > To unsubscribe, e-mail: [hidden email]
>> >
>> > For additional commands, e-mail: [hidden email]
>> >
>> >
>> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Julio Faerman]

Besides binding, we still need conversion and validation to use jersey
as the main framework. Perhaps it would be possible reuse struts 2
conversion and validation (the current best, IHMO), or even make this
"pluggable".

On Tue, Jan 27, 2009 at 3:22 PM, James Strachan
<[hidden email]> wrote:

> 2009/1/27 Paul Sandoz <[hidden email]>:
>>
>> On Jan 27, 2009, at 5:33 PM, James Strachan wrote:
>>
>>> 2009/1/27 Craig McClanahan <[hidden email]>:
>>>>
>>>> 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/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Marc Hadley]

On Jan 27, 2009, at 12:45 PM, Arul Dhesiaseelan wrote:

> It would be nice if JAX-RS defined a standard client-side API.  
> Currently, every implementation (Jersey, Resteasy, Restlet) provide  
> their own client APIs and it becomes cumbersome for tools to  
> interface with different implementations and had to use specific  
> client APIs when working with their resources. HTTP Client API is  
> one option, but they are not modeled around the resources which the  
> Jersey client API does it wisely.
>
> Any plans to provide a standard client API which can interoperate  
> with various JAX-RS implementations?
>

Its something we might look at in a 2.0 API. However, I think it could  
be quite tricky to get consensus around since the existing client APIs  
are all rather different.

Marc.

>
> Craig McClanahan wrote:
>> [hidden email] wrote:
>>> Well, it occurs to me that both JAX-RS and Jersey dosen't define  
>>> client-side API's (however, other JAX-RS based frameworks do, like  
>>> Restlet and RestEasy, if I'm not mistaken....)
>>>
>>> So to build a full Web app you have to use Jersey *and* something  
>>> else...
>>>
>>> (i'm reading your blog post by pieces, i must say...)
>>>
>> JAX-RS does not currently define any standard client side API, but  
>> Jersey most definitely does  And it works really well -- letting  
>> you share the provider machinery from the server side.  You can  
>> start with the Javadocs[1], read examples on Paul's blog[2], or  
>> look at nearly all the unit tests for jersey-server -- they use  
>> jersey-client to exercise the server side features.
>>
>> [1] https://jersey.dev.java.net/source/browse/*checkout*/jersey/tags/jersey-1.0.1/api/jersey/index.html
>> [2] http://blogs.sun.com/sandoz/category/REST
>>
>> Craig
>>>
>>>
>>> On Jan 27, 2009 3:45pm, James Strachan <[hidden email]>  
>>> 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 :). 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.
>>> >
>>> >
>>> >
>>> > Thoughts?
>>> >
>>> >
>>> >
>>> > --
>>> >
>>> > James
>>> >
>>> > -------
>>> >
>>> > http://macstrac.blogspot.com/
>>> >
>>> >
>>> >
>>> > Open Source Integration
>>> >
>>> > http://fusesource.com/
>>> >
>>> >
>>> >
>>> >  
>>> ---------------------------------------------------------------------
>>> >
>>> > To unsubscribe, e-mail: [hidden email]
>>> >
>>> > For additional commands, e-mail: [hidden email]
>>> >
>>> >
>>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[jstrachan]

2009/1/27 Julio Faerman <[hidden email]>:
> Besides binding, we still need conversion and validation to use jersey
> as the main framework. Perhaps it would be possible reuse struts 2
> conversion and validation (the current best, IHMO), or even make this
> "pluggable".

I guess you could plug in WebBeans into Jersey to do conversational
state bijection rather like Jersey supports dependency injection?

--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://fusesource.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Paul Sandoz]

HI James,

Nice post. Here is a link for implicit/explicit views:

   http://blogs.sun.com/sandoz/entry/mvcj

Nothing on the wiki yet :-( I tried posting a comment, but i need to  
sign up and it forwarded me to a page in German (automatic transparent  
proxies!) and so i gave up for now...

BTW the idea of the view approach came from Hudson, which uses it's  
own framework called Stapler. I refined it to work with Jersey/JAX-RS  
with a plugable system for template processing.

I am very keen to pursue this area further, but as of late i have not  
had the time to focus on this as much as i would like. So is is great  
to see the likes of yourself and others on the users list take an  
interest and help out :-)

Paul.

On Jan 27, 2009, at 4:45 PM, 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 :). 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.
>
> Thoughts?
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Arul Dhesiaseelan]

That would be awesome if 2.0 addresses this concern. It opens up room
for building highly interoperable restful services where services are
clients too and resource interaction is not limited by the client API.

Is 2.0 work done under existing JSR311 or a separate JSR?

-Arul

Marc Hadley wrote:

> On Jan 27, 2009, at 12:45 PM, Arul Dhesiaseelan wrote:
>
>> It would be nice if JAX-RS defined a standard client-side API.
>> Currently, every implementation (Jersey, Resteasy, Restlet) provide
>> their own client APIs and it becomes cumbersome for tools to
>> interface with different implementations and had to use specific
>> client APIs when working with their resources. HTTP Client API is one
>> option, but they are not modeled around the resources which the
>> Jersey client API does it wisely.
>>
>> Any plans to provide a standard client API which can interoperate
>> with various JAX-RS implementations?
>>
> Its something we might look at in a 2.0 API. However, I think it could
> be quite tricky to get consensus around since the existing client APIs
> are all rather different.
>
> Marc.
>
>>
>> Craig McClanahan wrote:
>>> [hidden email] wrote:
>>>> Well, it occurs to me that both JAX-RS and Jersey dosen't define
>>>> client-side API's (however, other JAX-RS based frameworks do, like
>>>> Restlet and RestEasy, if I'm not mistaken....)
>>>>
>>>> So to build a full Web app you have to use Jersey *and* something
>>>> else...
>>>>
>>>> (i'm reading your blog post by pieces, i must say...)
>>>>
>>> JAX-RS does not currently define any standard client side API, but
>>> Jersey most definitely does  And it works really well -- letting you
>>> share the provider machinery from the server side.  You can start
>>> with the Javadocs[1], read examples on Paul's blog[2], or look at
>>> nearly all the unit tests for jersey-server -- they use
>>> jersey-client to exercise the server side features.
>>>
>>> [1]
>>> https://jersey.dev.java.net/source/browse/*checkout*/jersey/tags/jersey-1.0.1/api/jersey/index.html 
>>>
>>> [2] http://blogs.sun.com/sandoz/category/REST
>>>
>>> Craig
>>>>
>>>>
>>>> On Jan 27, 2009 3:45pm, James Strachan <[hidden email]>
>>>> 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 :). 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.
>>>> >
>>>> >
>>>> >
>>>> > Thoughts?
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> >
>>>> > James
>>>> >
>>>> > -------
>>>> >
>>>> > http://macstrac.blogspot.com/
>>>> >
>>>> >
>>>> >
>>>> > Open Source Integration
>>>> >
>>>> > http://fusesource.com/
>>>> >
>>>> >
>>>> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Paul Sandoz]

On Jan 28, 2009, at 12:50 AM, Arul Dhesiaseelan wrote:

> That would be awesome if 2.0 addresses this concern. It opens up  
> room for building highly interoperable restful services where  
> services are clients too and resource interaction is not limited by  
> the client API.
>
> Is 2.0 work done under existing JSR311 or a separate JSR?
>

If JAX-RS 2.0 is undertaken (we have only just submitted the JAX-RS  
1.1 maintenance release and no discussions have started on a proposed  
2.0) then IIUC it will require a new JSR submission, which will result  
in a new JSR number.

Paul.

> -Arul
>
> Marc Hadley wrote:
>> On Jan 27, 2009, at 12:45 PM, Arul Dhesiaseelan wrote:
>>
>>> It would be nice if JAX-RS defined a standard client-side API.  
>>> Currently, every implementation (Jersey, Resteasy, Restlet)  
>>> provide their own client APIs and it becomes cumbersome for tools  
>>> to interface with different implementations and had to use  
>>> specific client APIs when working with their resources. HTTP  
>>> Client API is one option, but they are not modeled around the  
>>> resources which the Jersey client API does it wisely.
>>>
>>> Any plans to provide a standard client API which can interoperate  
>>> with various JAX-RS implementations?
>>>
>> Its something we might look at in a 2.0 API. However, I think it  
>> could be quite tricky to get consensus around since the existing  
>> client APIs are all rather different.
>>
>> Marc.
>>
>>>
>>> Craig McClanahan wrote:
>>>> [hidden email] wrote:
>>>>> Well, it occurs to me that both JAX-RS and Jersey dosen't define  
>>>>> client-side API's (however, other JAX-RS based frameworks do,  
>>>>> like Restlet and RestEasy, if I'm not mistaken....)
>>>>>
>>>>> So to build a full Web app you have to use Jersey *and*  
>>>>> something else...
>>>>>
>>>>> (i'm reading your blog post by pieces, i must say...)
>>>>>
>>>> JAX-RS does not currently define any standard client side API,  
>>>> but Jersey most definitely does  And it works really well --  
>>>> letting you share the provider machinery from the server side.  
>>>> You can start with the Javadocs[1], read examples on Paul's  
>>>> blog[2], or look at nearly all the unit tests for jersey-server  
>>>> -- they use jersey-client to exercise the server side features.
>>>>
>>>> [1] https://jersey.dev.java.net/source/browse/*checkout*/jersey/tags/jersey-1.0.1/api/jersey/index.html
>>>> [2] http://blogs.sun.com/sandoz/category/REST
>>>>
>>>> Craig
>>>>>
>>>>>
>>>>> On Jan 27, 2009 3:45pm, James Strachan  
>>>>> <[hidden email]> 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 :). 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.
>>>>> >
>>>>> >
>>>>> >
>>>>> > Thoughts?
>>>>> >
>>>>> >
>>>>> >
>>>>> > --
>>>>> >
>>>>> > James
>>>>> >
>>>>> > -------
>>>>> >
>>>>> > http://macstrac.blogspot.com/
>>>>> >
>>>>> >
>>>>> >
>>>>> > Open Source Integration
>>>>> >
>>>>> > http://fusesource.com/
>>>>> >
>>>>> >
>>>>> >
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[jstrachan]

Could a client API be included in a 1.1 maintenance release, or is
that a stretch too far :-)


On 28/01/2009, Paul Sandoz <[hidden email]> wrote:

>
> On Jan 28, 2009, at 12:50 AM, Arul Dhesiaseelan wrote:
>
>> That would be awesome if 2.0 addresses this concern. It opens up
>> room for building highly interoperable restful services where
>> services are clients too and resource interaction is not limited by
>> the client API.
>>
>> Is 2.0 work done under existing JSR311 or a separate JSR?
>>
>
> If JAX-RS 2.0 is undertaken (we have only just submitted the JAX-RS
> 1.1 maintenance release and no discussions have started on a proposed
> 2.0) then IIUC it will require a new JSR submission, which will result
> in a new JSR number.
>
> Paul.
>
>
>> -Arul
>>
>> Marc Hadley wrote:
>>> On Jan 27, 2009, at 12:45 PM, Arul Dhesiaseelan wrote:
>>>
>>>> It would be nice if JAX-RS defined a standard client-side API.
>>>> Currently, every implementation (Jersey, Resteasy, Restlet)
>>>> provide their own client APIs and it becomes cumbersome for tools
>>>> to interface with different implementations and had to use
>>>> specific client APIs when working with their resources. HTTP
>>>> Client API is one option, but they are not modeled around the
>>>> resources which the Jersey client API does it wisely.
>>>>
>>>> Any plans to provide a standard client API which can interoperate
>>>> with various JAX-RS implementations?
>>>>
>>> Its something we might look at in a 2.0 API. However, I think it
>>> could be quite tricky to get consensus around since the existing
>>> client APIs are all rather different.
>>>
>>> Marc.
>>>
>>>>
>>>> Craig McClanahan wrote:
>>>>> [hidden email] wrote:
>>>>>> Well, it occurs to me that both JAX-RS and Jersey dosen't define
>>>>>> client-side API's (however, other JAX-RS based frameworks do,
>>>>>> like Restlet and RestEasy, if I'm not mistaken....)
>>>>>>
>>>>>> So to build a full Web app you have to use Jersey *and*
>>>>>> something else...
>>>>>>
>>>>>> (i'm reading your blog post by pieces, i must say...)
>>>>>>
>>>>> JAX-RS does not currently define any standard client side API,
>>>>> but Jersey most definitely does  And it works really well --
>>>>> letting you share the provider machinery from the server side.
>>>>> You can start with the Javadocs[1], read examples on Paul's
>>>>> blog[2], or look at nearly all the unit tests for jersey-server
>>>>> -- they use jersey-client to exercise the server side features.
>>>>>
>>>>> [1]
>>>>> https://jersey.dev.java.net/source/browse/*checkout*/jersey/tags/jersey-1.0.1/api/jersey/index.html
>>>>> [2] http://blogs.sun.com/sandoz/category/REST
>>>>>
>>>>> Craig
>>>>>>
>>>>>>
>>>>>> On Jan 27, 2009 3:45pm, James Strachan
>>>>>> <[hidden email]> 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 :). 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.
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > Thoughts?
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > --
>>>>>> >
>>>>>> > James
>>>>>> >
>>>>>> > -------
>>>>>> >
>>>>>> > http://macstrac.blogspot.com/
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > Open Source Integration
>>>>>> >
>>>>>> > http://fusesource.com/
>>>>>> >
>>>>>> >
>>>>>> >
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://fusesource.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Paul Sandoz]

On Jan 28, 2009, at 9:34 AM, [hidden email] wrote:

> Could a client API be included in a 1.1 maintenance release, or is
> that a stretch too far :-)
>

Unfortunately the latter. A maintenance release is not suitable for  
new features of the scope of the client API.

Paul.

>
> On 28/01/2009, Paul Sandoz <[hidden email]> wrote:
>>
>> On Jan 28, 2009, at 12:50 AM, Arul Dhesiaseelan wrote:
>>
>>> That would be awesome if 2.0 addresses this concern. It opens up
>>> room for building highly interoperable restful services where
>>> services are clients too and resource interaction is not limited by
>>> the client API.
>>>
>>> Is 2.0 work done under existing JSR311 or a separate JSR?
>>>
>>
>> If JAX-RS 2.0 is undertaken (we have only just submitted the JAX-RS
>> 1.1 maintenance release and no discussions have started on a proposed
>> 2.0) then IIUC it will require a new JSR submission, which will  
>> result
>> in a new JSR number.
>>
>> Paul.
>>
>>
>>> -Arul
>>>
>>> Marc Hadley wrote:
>>>> On Jan 27, 2009, at 12:45 PM, Arul Dhesiaseelan wrote:
>>>>
>>>>> It would be nice if JAX-RS defined a standard client-side API.
>>>>> Currently, every implementation (Jersey, Resteasy, Restlet)
>>>>> provide their own client APIs and it becomes cumbersome for tools
>>>>> to interface with different implementations and had to use
>>>>> specific client APIs when working with their resources. HTTP
>>>>> Client API is one option, but they are not modeled around the
>>>>> resources which the Jersey client API does it wisely.
>>>>>
>>>>> Any plans to provide a standard client API which can interoperate
>>>>> with various JAX-RS implementations?
>>>>>
>>>> Its something we might look at in a 2.0 API. However, I think it
>>>> could be quite tricky to get consensus around since the existing
>>>> client APIs are all rather different.
>>>>
>>>> Marc.
>>>>
>>>>>
>>>>> Craig McClanahan wrote:
>>>>>> [hidden email] wrote:
>>>>>>> Well, it occurs to me that both JAX-RS and Jersey dosen't define
>>>>>>> client-side API's (however, other JAX-RS based frameworks do,
>>>>>>> like Restlet and RestEasy, if I'm not mistaken....)
>>>>>>>
>>>>>>> So to build a full Web app you have to use Jersey *and*
>>>>>>> something else...
>>>>>>>
>>>>>>> (i'm reading your blog post by pieces, i must say...)
>>>>>>>
>>>>>> JAX-RS does not currently define any standard client side API,
>>>>>> but Jersey most definitely does  And it works really well --
>>>>>> letting you share the provider machinery from the server side.
>>>>>> You can start with the Javadocs[1], read examples on Paul's
>>>>>> blog[2], or look at nearly all the unit tests for jersey-server
>>>>>> -- they use jersey-client to exercise the server side features.
>>>>>>
>>>>>> [1]
>>>>>> https://jersey.dev.java.net/source/browse/*checkout*/jersey/tags/jersey-1.0.1/api/jersey/index.html
>>>>>> [2] http://blogs.sun.com/sandoz/category/REST
>>>>>>
>>>>>> Craig
>>>>>>>
>>>>>>>
>>>>>>> On Jan 27, 2009 3:45pm, James Strachan
>>>>>>> <[hidden email]> 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 :). 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.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thoughts?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> James
>>>>>>>>
>>>>>>>> -------
>>>>>>>>
>>>>>>>> http://macstrac.blogspot.com/
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Open Source Integration
>>>>>>>>
>>>>>>>> http://fusesource.com/
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[jstrachan]

2009/1/28 Paul Sandoz <[hidden email]>:
>
> On Jan 28, 2009, at 9:34 AM, [hidden email] wrote:
>
>> Could a client API be included in a 1.1 maintenance release, or is
>> that a stretch too far :-)
>>
>
> Unfortunately the latter. A maintenance release is not suitable for new
> features of the scope of the client API.

It was worth a try :)

While I'm pushing my luck, how about adding support for the ;q=1.0
type priority/quality modifier to 1.1?
https://jsr311.dev.java.net/issues/show_bug.cgi?id=46
http://gewis.win.tue.nl/~koen/conneg/rfc2296.txt

Its a fairly minor change to the spec (no API change and a minor spec
update describing the sorting algorithm)? Until 2.0 it could even be
declared as an optional feature respecting the quality in sort order
(since there's nothing to stop you using RFC2296 mime types in JAX-RS
now) so that JAX-RS implementations don't have to implement it but
they are encouraged if possible.

Due to https://jsr311.dev.java.net/issues/show_bug.cgi?id=64 1.1 is
already having a minor change to support comma separated MIME types in
@Produces/@Consumes so it might be a good time to do both together?
(commas and ;q=1.0 allowed when parsing MIME strings in JAX-RS).

--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://fusesource.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Paul Sandoz]

On Jan 28, 2009, at 10:55 AM, James Strachan wrote:

> 2009/1/28 Paul Sandoz <[hidden email]>:
>>
>> On Jan 28, 2009, at 9:34 AM, [hidden email] wrote:
>>
>>> Could a client API be included in a 1.1 maintenance release, or is
>>> that a stretch too far :-)
>>>
>>
>> Unfortunately the latter. A maintenance release is not suitable for  
>> new
>> features of the scope of the client API.
>
> It was worth a try :)
>
> While I'm pushing my luck, how about adding support for the ;q=1.0
> type priority/quality modifier to 1.1?
> https://jsr311.dev.java.net/issues/show_bug.cgi?id=46
> http://gewis.win.tue.nl/~koen/conneg/rfc2296.txt
>
> Its a fairly minor change to the spec (no API change and a minor spec
> update describing the sorting algorithm)?

I do not agree it is such a minor spec change as that for comma  
separated strings. It will require a change to the resource matching  
algorithm, step 3 of section 3.7.2, which i think will time for the EG  
to digest and review.

Note that the MR is now in review:

   http://jcp.org/aboutJava/communityprocess/maintenance/jsr311/311ChangeLog.html

Paul.

> Until 2.0 it could even be
> declared as an optional feature respecting the quality in sort order
> (since there's nothing to stop you using RFC2296 mime types in JAX-RS
> now) so that JAX-RS implementations don't have to implement it but
> they are encouraged if possible.
>
> Due to https://jsr311.dev.java.net/issues/show_bug.cgi?id=64 1.1 is
> already having a minor change to support comma separated MIME types in
> @Produces/@Consumes so it might be a good time to do both together?
> (commas and ;q=1.0 allowed when parsing MIME strings in JAX-RS).
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]