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
> >
> >