Hi Marek,
I agree that if you pick a specific convention, you might break
compatibility and so on. But if you allow people to choose their
conventions, it can be backward compatible in the three points that
you mentioned. It is also the developers intention so its his decision
to use it one way or another.
The advantage of allow configuring a convention is that the code below
would work in any implementation without any change on the codebase.
Currently its all about extensions to the implementation that are done
in different way in each one of them (if even supported).
It is the ability to give the developer an option: to go for CoC or
not, instead of forcing him not to do it.
Regards
Guilherme Silveira
Caelum | Ensino e Inovação
http://www.caelum.com.br/
On Thu, Mar 17, 2011 at 7:40 AM, Marek Potociar
<marek.potociar_at_oracle.com> wrote:
> Hello *,
>
> FWIW, here's my take on the annotation CoC topic so far:
>
> - Resource method annotations (@GET, @POST ...) cannot be made optional unless we decide to severely break BW
> compatibility with JAX-RS 1.x spec. Also, other than reducing the amount of code in the most simple cases, I do not
> really see the more significant benefit of such change. Thus it seems to me, the cost/value ratio in this case is too
> high. I would not support this change.
>
> - As for @Path annotation, I would not want to make it optional either, because I am concerned about the readability and
> maintainability of the code below due to the potential side effects[1]. To workaround the mainainability issues, we
> would need to specify a lots of rules, which IMHO compromises the main reason of CoC as it violates the KISS principle.
>
> - As for specifying the default value of the @Path annotation, I can see certain limited benefit in the early
> prototyping phase of a project. And since it is not breaking BW compatibility, I'd be willing to consider a proposal
> that would be aligned with principles stated in JSR250. Being the part of the same umbrella specification, we should
> converge with related specifications rather than diverge from them.
>
> Obviously, as demonstrated by the code below, there is a plenty of space in implementations for adding lots of
> additional flexibility dimensions. I am not sure however that we should be bringing all those dimensions into the spec.
> Also, it seems questionable how the code below actually benefits the CoC. How do you know that this class is actually a
> root resource? Obviously, you need to configure it somewhere somehow either in a deployment descriptor or programmatically.
>
> Kind regards,
> Marek
>
> [1] In JAX-WS where @WebMethod (specified in JSR-181) is optional, this optionality is causing frequent issues on the
> customer side. If someone adds a new annotated method to a WS interface or tries to customize a SOAP signature on just a
> single method, suddenly all existing not annotated web service methods from the WS interface.
>
> On 03/16/2011 09:17 PM, Guilherme Silveira wrote:
>> public class FooResource {
>>
>> @GET String customer()
>>
>> }
>>
>> This is what we support today... that's why I am proposing all those interfaces.
>