Hi Guilherme,
I certainly don't want to sound like I don't like your ideas. Yet to me, allowing people to completely use their own
convention is a non-goal for this spec. I am quite skeptic about us trying to standardize a generic framework as part of
this specification that would impose a particular design upon all implementations of the spec.
Kind regards,
Marek
On 03/17/2011 11:51 AM, Guilherme Silveira wrote:
> 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.
>>