Argh... I just sent it once second ago, sorry. I will post a comments there.
Thanks
Guilherme Silveira
Caelum | Ensino e Inovação
http://www.caelum.com.br/
On Sat, Mar 12, 2011 at 2:57 PM, Markus KARG <markus_at_headcrashing.eu> wrote:
> It might be best if you just would post in your very own words into the JIRA
> item what you like to propose exactly and how you want it to be working
> like. This would be a good foundation for the future dicussion of that
> issue.
>
>> -----Original Message-----
>> From: guilherme.silveira_at_gmail.com
>> [mailto:guilherme.silveira_at_gmail.com] On Behalf Of Guilherme Silveira
>> Sent: Samstag, 12. März 2011 18:52
>> To: jsr339-experts_at_jax-rs-spec.java.net
>> Subject: [jsr339-experts] Re: Convention Over Configuration
>>
>> >> 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
>> >
>> >
>
>