>> 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.
Hi Markus,
My proposal is a little bit different from what Roberto extracte: it's
not *one* specific convention, but the capability of deciding
conventions on my own projects. So if Bill likes one convention and
you like another, each one has its own jar... and both jars work with
any JAX-RS implementation. That's what we do nowadays. If someone
doesn't want any conventions, just don't add it.
So the solution tries to satisfy everyone, instead of satisfying just ourselves.
I'm gonna post in in another email together with what we are looking for.
Regards
Guilherme Silveira
Caelum | Ensino e Inovação
http://www.caelum.com.br/
On Sat, Mar 12, 2011 at 2:13 PM, Markus KARG <markus_at_headcrashing.eu> 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.
>
> Regards
> Markus
>
>