On 3/12/11 3:41 AM, Markus KARG wrote:
>> Having applications behave differently per JAX-RS implementation is not
>> in the best interest of JAX-RS
>
> Remind that this is JAX-RS 2.0 and not JAX-RS 1.2, so we are free to define
> a changed behaviour if a majority of experts vote for it. 100% backwards
> compatibility is not essential
Nope. This isnt an anything goes specification. Java EE just doesn't
work that way. Java EE specifications are usually (always? required
to be?) backward compatible with previous versions, as is the Java
language. To make such a simple specification as Jax-rs not backward
compatible is just irresponsible.
, otherwise we couldn't fix some particular
> problems anyway. I have no problem with changing my application when
> migrating to 2.0, while I would have a problem with that when migrating to
> 1.2.
>
>
>> For your users because they are using your framework. I know it will
>> break mine.
>
> Possibly is more a problem of your framework then and less one of the
> specification?
>
FYI: Resteasy does have thousands of users and is used by many of our
customers in production.
But this isn't a problem with Resteasy. As I said before, I and I've
seen others use getXXX method signature names to specify resource
locator methods all the time. Besides, its just confusing to have a
method signature define behavior. That @Path("/path") Object foo()
would have different behavior than @Path("/path") Object getFoo() is
just ridiculous. So, I would not support deriving the HTTP method
binding from a method signature.
Although I do not like deriving Path information from method signatures
or method names or class names, I would support it if both Jersey and
CXF folks like the idea. And only if the path derived was *exactly* the
same as the method or class name:
I.e.
@Path
public class FooResource {
@Path
@GET String customer()
}
mapped to "/FooResource/customer". Having to remember some pattern on
how a class or method name is mapped to a url is counter-intuitive, IMO.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com