On 17.03.2011, at 11:40, Marek Potociar 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.
o.k - it would be a minor optimization either.
>
> - 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.
I cannot agree with that. JPA, EJB work also with CoC and there are no issues. The mechanics are even similar. E.g. in JPA the class name gets mapped to a table and an attribute to column. Annotations are optional, except @Entity.
IMHO readability of the code is the best without any annotations :-)
Putting the name of the method inside @Path would violate the DRY principle.
*DRY + CoC should be a main theme across all specs in Java EE 7*
>
> 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.
O.k. but this is the thing with CoC. A refactoring of a JPA-Entity without annotations could break the mapping.
>
> 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.