On Thu, Oct 31, 2013 at 4:47 PM, cowwoc <cowwoc_at_bbs.darktech.org> wrote:
> On 31/10/2013 12:36 PM, Cameron Jones wrote:
>
>> This isn't the only problem though, it's just another case of JAX-RS
>> using different DI rules.
>>
>> Another example is @*Param, these are automatically injected in JAX-RS
>> whereas in DI they require @Inject.
>>
>
> My view is that JAX-RS shouldn't mandate *any* injection rules. I
> understand that you're expecting JAX-RS to ensure DI portability so I can
> easily switch between one DI provider to another without having to change
> my JAX-RS code but for me this is a non-goal. I *should* have to change my
> code if I move from Guice to Spring to HK2. First of all, people change DI
> providers as often as they change databases (almost never). Secondly,
> JAX-RS is not in the DI portability business, nor should it be. Leave that
> up to JSR 330 extensions that will one day make DI providers portable.
>
> Gili
>
I expect portability between JAX-RS implementations because that's the
point of the specification. Once in JAX-RS you should be able to port that
code between impls with no code changes, and you can.
Since DI isn't in JAX-RS then i wouldn't expect to be able to port any DI
code between JAX-RS implementations.
Changing (or even having multiple DI choices) in a JAX-RS implementation is
an implementation specific feature (if at all) so you immediately have no
portability guarantees of JAX-RS when using those features.
The only DI specification which guarantees portability is CDI, and even
that needs implementation specific code to get up and running.
JSR-330 is non-portable. It consists of some loosely defined annotations
and some javadoc and that's it. It would be up to an implementation like
Jersey to provide the portability between DI containers under the
specification of JAX-RS. That turns JAX-RS into a DI abstraction layer
which (debatably it already is) imposes much larger requirements on
implementations.
Technically, at present there need be no DI in JAX-RS. The DI features
represent a faux-DI model which is a throw back from the arcane days when
DI didn't exist in the evolved forms we see today.
Maybe JAX-RS should just eradicate DI from its makup and just be a regex
request dispatcher?
cam