On 12.03.2011, at 18:13, 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.
>
> I have to disagree. First, I discussed the possibility to cut backwards
> compatibility with Paul Sandoz and Marc Hadley before and they agreed that
> it is *not* impossible in several cases. Second, even Java EE has cut
> backwards compatibility already, e. g. by dropping support for CMP. Please
> don't mix your personal opinion with our actual policy. Nobody forbids
> breaking backwards compatibility actually, at least I have not found any
> written rule about that so far. Even in the Java language there are ongoing
> discussion about breaking backwards compatibility to allow new features.
>
>> FYI: Resteasy does have thousands of users and is used by many of our
>> customers in production.
>
> That might be the case but those are not Resteasy V.* users but users of a
> particular version of your framework. So they will understand if there is a
> good reason that a feature will break in a dot-zero release, since they can
> stick with an older product line if they don't want to. Also, as hard as
> this sounds, this EG is about JAX-RS but not just about the particular
> problems of particular implementations. As it seems other implementors do
> not see or share this problem.
>
>> 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.
>
> What will actually break if those now will be assumed as having @GET in
> future?
>
>> Besides, its just confusing to have a
>> method signature define behavior.
>
> This is just your opinion. In JAXB for example I like the idea of
> implementing afterUnmarshal() without any further need to add any
> annotation, registration or implements clause. The pure name of the method
> makes JAXB work. So why not copying that behaviour? I do not see that your
> personal opinion should stop us from adding his proposal to the list of
> ideas to discuss, even if I personally do not see the need for this
> particular functionality. This is an open collection of ideas. Let's add it
> and see in a later voting whether we find a majority for it,
>
>> 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.
>
> It's your freedom to vote against it as soon as the voting is open. But we
> should not pre-judgde his proposal before the discussion about the details
> of this issue was officially opened (is it?).
>
>> 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.
>
> It's your personal feeling. I personally think is is actually intuitive to
> get exactly that mapping. If it would be my proposal (actualyl it is not, I
> just like the core idea) I would even remove the need for both @Path, as it
> is rather obvious that this mapping is what the programmer wants to reach by
> solely putting @GET there.
@Markus,
I have to absolutely agree (this time :-)) with you and the segment above. JPA and JAXB use similar Convention over Configuration semantics.
I would appreciate to be able to make as many annotations as only possible optional.
In perfect world, something like:
public class FooResource {
@GET String customer()
}
should be mapped to: /FooResource/customer
thanks
adam
>
> Regards
> Markus
>