> Having applications behave differently per JAX-RS implementation is not in
> the best interest of JAX-RS
It didn't make sense. Of course they wouldn't. I don't believe anyone
would suggest that.
> For your users because they are using your framework. I know it will break
> mine.
Again, no it wouldn't. If they didn't change the strategy, it wouldn't
break anyone's app.
I can show code that does backward compatibility and provides
customized support. Its easy and it already exists. It's just the
usage of chain of responsibility.
You probably can't understand that it would not break anyone's app
because the current way things are, if you change the way one
annotation is read, it breaks compatibility. And thats what I am
trying to fight against. To still support this style and *add* support
for the programmatic configuration - and thus CoC.
regards
Guilherme Silveira
Caelum | Ensino e Inovação
http://www.caelum.com.br/
On Fri, Mar 11, 2011 at 2:10 PM, Bill Burke <bburke_at_redhat.com> wrote:
>
>
> On 3/11/11 11:43 AM, Guilherme Silveira 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.
>>
>> So that would be *your* custom router. Mine could be different. But by
>> exposing the model, anyone would be able to do it the way they feel
>> more productive for themselves. The way the configuration is done
>> nowadays, its imposed as annotations+strings.
>>
>
> Having applications behave differently per JAX-RS implementation is not in
> the best interest of JAX-RS
>
>
>>> 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.
>>
>> Same thing here. My custom router would take care of it, no one would
>> ever break.
>>
>> We have been doing this for more than an year, allowing annotation
>> config, programmatic config, conventions and convention configuration
>> (and even xml config if someone wants)... no compatibility was ever
>> broken and anyone is free to make the framework work with the code
>> they want to write, instead of making the code the framework wants
>> them to make.
>>
>
> For your users because they are using your framework. I know it will break
> mine.
>
>> Again, no compatibility breaks.
>>
>> I don't know if you agreed by the refactoring though. That string and
>> annotations refactoring does not exist in IDE's, where as code
>> refactoring exists.
>>
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>