My comments below:
> I think we may be able to address some of this for JAX-RS
> 2.0.
Great!
> I understand. It is always the challenge after 1.0 :-) FWIW
> i am willing to break stuff for 2.0 if the results are
> significantly better.
Super.
> > Alternatively, since the standard annotations are the
> same you could have a pluggable backend instead so it would
> work with both guice, spring and cdi/weld ?
> >
>
> Yes, that might be possible with 330.
I think this is the solution you should go for. It is NOW my solid experience that having more then one dependency manager installed at the same time and having them interoperate is an invitation to complications and bugs (in fact, this is the very problem we have now with jersey + weld/cdi and this is not the first time I got these kind of problems).
So I would STRONGLY recommend to that jersey leaves ALL dependency injection to a pluggable backend. As long as you just have to delegate and not interoperate like now then, I guess it would be quite simple to support multiple implementations (and it would surprise me if the implementations had to contain much code).
> But yes we need to document n the user guide what works in
> Jersey, which should be all the required aspects specified
> by JAX-RS 1.1.
Yes, the only source I have now for this info is the mailing list + my own experiments.
> Only CDI magic :-) Jersey needs to register a CDI extension
> so that it can adapt the injection targets and inject at the
> right point in the CDI managed life-cycle. The problem is
> that CDI magic gets invoked before Jersey is properly
> started (before the Jersey servlet is initialized) thus it
> needs to cache the processor injection target events.
Yea, complicated..... I had a similar but simpler situation where I needed my Junit tests to be CDI injected and I just called into beanmananger to inject into the instance at setup of the test. Of cause this means that the test itself is not managed by CDI - only injected with CDI objects. This is also more or less what I personally need for weld/cdi+jersey. (no need to have jersey controllers CDI managed actually).
> By default JAX-RS resource classes are managed in the
> request scope. This actually requires more CDI magic to
> modify the internal model such that the scope of a resource
> class is modified from being dependent to being request
> scoped. We need to address this as well as better @Inject
> support.
Ok. Thanks for the info. I will make sure my controllers are singletons if possible to avoid problems then.
> > Instead you should react on the presense of
> "beans.xml" like Weld and assume that all beans are mananged
> by CDI/weld if present.
> >
>
> Jersey does already. That is what the CDI extension
> registration does so that processor injection targets can be
> adapted. Jersey defers to CDI for instantiate when CDI is
> present.
If jersey does then, then why do I ALSO need to annotate jersey controllers with CDI/javax.inject stuff in order for jersey to support injecting CDI managed objects into jersey controllers ?
> There is also the case when CDI is not present and
> @ManagedBean is utilized. This means Jersey defers to the
> container to instantiate, inject, then Jersey injects, then
> Jersey manages the life-cycle. As i said this whole area is
> complex.
Yes where - that's why we need some documentation or even BETTER removing all that complexity alltogether by removing jersey's own dependency manager stuff :-)
Cheers,
Morten