> -1, implied rules like this are unintuitive
The advantage of exposing the semantic model of your domain is that
anyone can built those defaults the way they want, without breaking
the spec. So if JAX-RS provides a model where I can do:
routes.add(new CustomRouteHandler());
The team can provide its custom route handlers (or jar'ed ones), such as:
public boolean canHandler(URI uri) {
return true based on some default;
}
It's a matter of exposing your model, instead of forcing specific
configuration approaches. Then, each one can decide on its own what is
best and still be compatible.
> and can break clients easy when
> you refactor code by accident.
On the contrary, not being DRY is the root of refactor problems. What
happens nowadays if you change the annotation path and don't change
all the URIBuilders (which are not DRY, non conventioned)? It breaks.
If conventions and DRY where followed, nothing would.
Repetition by annotation and strings, is the root of breaking things
after refactoring. Those are the structures that refactor in eclipse
and other IDEs will not understand... thats the problem with
annotation and string based programming.
Regards
Guilherme Silveira
Caelum | Ensino e Inovação
http://www.caelum.com.br/
On Fri, Mar 11, 2011 at 10:03 AM, Bill Burke <bburke_at_redhat.com> wrote:
> -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
>