I think the proposal is valid and I remember having had similar ideas
before. So I would support replacing
@Path("foo") public T foo()
by just
@Path public T foo()
I wouldn't assume any http method (so not removing @GET) but I would assume
the value of @Path. I don't see negative effects, so we should add the idea
to the list and discuss and vote later what actual risks could occur etc.
Regards
Markus
> -----Original Message-----
> From: Bill Burke [mailto:bburke_at_redhat.com]
> Sent: Freitag, 11. März 2011 14:03
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: Convention Over Configuration
>
> -1, implied rules like this are unintuitive and can break clients easy
> when you refactor code by accident. I was against this in JAX-RS 1.0:
>
> @Path
> public String get()
>
> Where @GET was implied by the method prefix name "get". Sometimes a
> tiny bit more verbosity goes a long way to help new code maintainers
> understand what is going on (or help you remember what you did).
>
> I do wish though that @Path's value() was a default of "" or "/".
>
> On 3/11/11 2:49 AM, Adam Bien wrote:
> > Hi Guilherme,
> >
> > you mean:
> >
> >>>> @Path("something")
> >>>> @GET
> >>>> public Response something(...
> >>>>
> >>>> @Path("something")
> >>>> class SomethingResource {
> >>>> }
> >
> > should be
> >
> >
> > @Path
> > public Response something
> >
> > and
> >
> > @Path
> > class SomethingResource ?
> >
> >
> > Then +1. I get questions in every workshop, why we have to specify
> that redundantly. We cannot go to far, because a JAX-Resource can be
> also an EJB or managed bean at the same time.
> >
> > In general - we should minimize the total amount of required
> annotations.
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com