On Wed, Oct 30, 2013 at 5:42 PM, cowwoc <cowwoc_at_bbs.darktech.org> wrote:
> On 30/10/2013 12:19 PM, Cameron Jones wrote:
>
> This predates HK2 as was from JAX-RS 1.0. When you consider that when it
> was developed there was no DI other than XML Spring and annotations were a
> new feature for JDK5 then this requirement can probably be seen as a relic
> with established ground which has since been superseded by the
> establishment of alternate conventions in CDI. Much the same as @Context
> wouldn't exist if @Inject were available at the time.
>
> Given that JAX-RS chose to retain it for v2 and Jersey is the RI for
> JAX-RS, the likelihood of this being repealed or willfully disregarded is
> unlikely.
>
>
> It seems to me that, except for HK2, no one is bothering to implement
> this requirement. Not now, nor back in Jersey 1.0. It should be removed
> because there is no practical need for it, nor is it providing any
> practical benefit because no one is following it (hence it doesn't improve
> portability).
>
>
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.
It's not possible to implement JAX-RS using a DI container with simple
configuration, so the DI container is really just a tool which JAX-RS
implementation uses for modularity and integration within an EE server or
SE environment.
So, really what Jersey should be doing is implementing the JAX-RS DI model
while deferring the dependency context to a container through some internal
abstraction which the Guice/Spring/HK2/CDI extensions implement.
HK2 doesn't really do anything special compared to other DI containers,
> it's just a JSR-330 container.
>
> I'm sure it's feasible for any DI container to be configured for the
> JAX-RS model, but such non-trivial configuration would require a codebase
> for the task.
>
>
> I don't think you can implement the above requirement for constructors
> for Guice no matter how much code you threw at it. Guice has its own rules
> for constructor resolution (as does Spring) and there are no facilities for
> altering these. And again, I fully agree with them... because this kind of
> thing should be out of scope for JAX-RS.
>
>
If you were to change constructor rules within Guice it would probably mess
up any other DI you wanted to do...so not really an option.
I think that the best place for JAX-RS rules is within the JAX-RS
implementation.
> Sure, the furthest i got is in trying similar integration with SE CDI.
> I probably got about as far as you have but had to stop to get on with some
> other work.
>
>
> I haven't seen a single successful DI integration with Jersey except
> for HK2. Even the integrated Spring module isn't as functional as it seems.
> To me this is a "code smell" that indicates a design/architecture-level
> problem.
>
> Gili
>
Looking through the JSR-339 mailing lists i found some discussion and a
prospective proposal for enabling JSR-330 support in JAX-RS:
https://java.net/projects/jax-rs-spec/pages/DI
https://java.net/projects/jax-rs-spec/lists/jsr339-experts/archive/2011-09/message/39
https://java.net/projects/jax-rs-spec/lists/jsr339-experts/archive/2012-01/message/30
I'm not sure if there has been any movement in the area but it seemed like
it was on track as a contender for JAX-RS 2.1
If this is the case, then since the whole point of JSR-330 integration is
to be able to plug in DI containers then it would seem that this might be
an enabler.
Cam