On Apr 22, 2010, at 6:59 PM, Morten wrote:
>> Please log an issue if you want to support CDI
>> with Weld on SE, and any help on that area would be much
>> appreciated.
>
> I will log an issue with an example that is not working. I will get
> back to you on that. I also have an older message from you about
> Java SE support but it was a bit too difficult for me to go forward
> with the limited info to go with. I hope that if I send you a non-
> working simple example then we might be able to get it to work
> together?
>
Thanks. Priority wise fixing issues for CDI on EE6 is higher.
>> This area is very complex so if you can send reproducible
>> test cases for what does not work for you on EE 6 that would
>> help us find issues and resolve them faster.
>
> Will try do as noted in other mail.
>
Thanks.
>> I too would like to see more use of the 330 annotations. If
>> JAX-RS 1.0 had been done while 330 was there it could be
>> very different :-) I also want to rip out the Jersey DI
>> internals and replace with a DI framework so we can maintain
>> less code. This obviously has some large consequences in
>> terms of re-factoring, breaking API changes and core
>> dependencies. I would like to use Guice because i think it
>> is superior to CDI but alas there are some limitations. So
>> perhaps Weld instead.
>
> Yea, please go with you feelings here - Cut the code and throw it
> away today :-) I would be much happier to have the whole integration
> challenge disappear and have you great REST guys, that produced this
> wonderful framework work, work on even better REST support
> (HATEOS ?) instead of yet-another dependency framework inside Jersey
> that subtracts value rather then adds value to the framework (but
> yes, I understand that history has a role in you where originally
> first - no longer true).
>
I think we may be able to address some of this for JAX-RS 2.0.
> I would not mind if the next version of Jersey would have some
> incompatibilities in order to align with other Java6 EE standards. I
> guess you want some degree of backwards compatibility, so I would go
> for a little tool (annotation processor ?) that f.x at compile time
> change all jersey annotations to standard annotations. The biggest
> problem with java is the unwillingness to cleanup things because of
> a 100% mindset on "backwards compatibility" that overcomplicates
> Java. If users want the old api then they should not upgrade their
> jersey libs. But anyway thats my personal opinion.
>
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.
> Besides, I would MUCH prefer to be able to use the same library in
> and outside a web container, and since Weld works both places I
> think it is a perfect choice (and logical since it is already being
> used in Glassfish 3) - not Guice. I earlier had a look at Spring and
> Guice and so far I do prefer CDI/Weld and find it quite powerful.
> Not sure what you need Guice for.
Technical speaking i think Guice has a cleaner design. I prefer it's
explicit and modular binding model.
> 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.
>> There is a current limitation in Jersey, specified but not
>> required by JAX-RS 1.1, for the better integration of
>> @Inject. Namely support for constructor injection or the use
>> of @Inject on setter methods etc.
>
> Right now I can live with the limitations. I just need what you have
> to work 100% reliable out-of-the-box including excellent error
> handling and documentation of the integration.
>
I did talk about what works at the GF 3 release event and the preso
should be online.
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.
>> Jersey does not implement this yet. Two reasons:
>>
>> 1) Weld 1.0 was finished was integrated into GF very late
>> into the release process. You would not believe the
>> scrambling
>> around we had to do just to get
>> the current functionality to work!
>
> Yes, from what I have looked briefly in the source it seems like you
> had to do some magic stuff which is properly not 100% reliable.
>
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.
>> 2) The area of constructor injection requires much more
>> complex integration with CDI, potentially modifying/adapting
>> the
>> models that CDI uses to work out
>> what are injection targets and what can provide references.
>> It potentially may require
>> breaking changes to some of the
>> Jersey APIs.
>>
>> We plan to tackle 2) before GF 3.1 is released.
>
> Again, I would much prefer a focus on getting the current
> integration functionality to work out of the box in a reliable and
> well documented way. It would also be nice if you would not require
> special CDI annotations on controllers in order to work with weld
> (CDI does not normally require annotations in order for beans to be
> mananged).
Everything is a managed bean in CDI :-)
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.
> 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.
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.
Paul.