On 31/10/2013 1:07 PM, Cameron Jones wrote:
> On Thu, Oct 31, 2013 at 4:47 PM, cowwoc <cowwoc_at_bbs.darktech.org
> <mailto: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.
There are many components of a JAX-RS application that are not
portable, including the underlying database. You're not going to be able
to mandate everything. The only portability guarantee JAX-RS should make
is with respect to the behavior of its own classes. Injection of classes
should be out of scope. The most it should do (if it does anything at
all) is guarantee that using the same DI across multiple JAX-RS
implementations is portable (meaning, I should be able to migrate from
Jersey to RESTEasy, using Guice in both cases, without major problems).
> 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.
Only with respect to DI. The core JAX-RS classes will behave the same.
> 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.
I agree. JSR-330 is a step in the right direction but it is far
from complete. This is why I advocate that JAX-RS should omit any
mention of DI and leave it up to JSR-330 and friends to figure this out
in the future.
Gili