public class FooResource {
@GET String customer()
}
This is what we support today... that's why I am proposing all those interfaces.
Regards
Guilherme Silveira
Caelum | Ensino e Inovação
http://www.caelum.com.br/
On Wed, Mar 16, 2011 at 5:11 PM, Adam Bien <abien_at_adam-bien.com> wrote:
>
> 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
>>
>
>
>