> I tend to agree with this one.
Hi Marek, would you change your mind if you didnt have to use the
annotation, stick to your way of coding and be backward compatible?
Meaning that you would remove 90% of the required annotations. That is
what I am trying to offer.
> Again, I know this point has been argued/discuessed in JAX-RS 1.0. Don't understand why we would need to bring it up again.
Because the development world changed since JAX-RS 1.0. If the
frameworks don't adapt to new ways of coding... not just adding new
configurations, they will be stuck in the past.
If the developers still work the same way they used to do, they are
stuck in the past. That might be an option, but it is not what I
desire for the java dev community.
My main concern is about code and design, that's why I will have more
to talk on those issues than in features (except for hypermedia, of
course).
Regards
Guilherme Silveira
Caelum | Ensino e Inovação
http://www.caelum.com.br/
On Fri, Mar 11, 2011 at 1:35 PM, Marek Potociar
<marek.potociar_at_oracle.com> wrote:
> Hi Bill,
>
> On 03/11/2011 04:01 PM, Bill Burke wrote:
>> How would you tell the difference between a sub resource locator and a @GET request if the HTTP method was determined by
>> the method signature? I know I use getXXX() method signature names for some of my resource locator methods. I'm sure
>> others do as well.
>
> I tend to agree with this one.
>
>> Also, if you were implicitly building URI mappings, how would you tell the different between an empty path "" and
>> whether or not you wanted an implicit mapping. Define new annotations? -1.
>
> We may consider approaching the default @Path annotation value in a way similar to the JSR250. That would introduce
> requested convention over configuration at least to some extent. If one wants to instead configure the empty path "",
> one would use @Path(""), same as today.
>
>> I think adding any of this would greatly increase the risk of breaking existing applications.
>
> Provided the @Path annotation does not have a default value in JAX-RS 1.x, what risk of breaking existing applications
> do you see in this particular case?
>
> Kind regards,
> Marek
>