Hi Poul,
Thanks for your feedback. Comments below:
--- Den tors 22/4/10 skrev Paul Sandoz <Paul.Sandoz_at_Sun.COM>:
> Sorry to hear your CDI experience is not good.
Yea, my experience with pure Jersey has been very good. It is only when I try to use it with JEE 6 stuff such as CDI or external dependency managers that I run into all sorts of strange, unpleasant problems. Problems that is similar to when I am trying out beta-quality software and not the core Jersey part which is EXCELLENT QUALITY. Problems that takes a LOT of time and debugging since errors/documentation is limited in this area.
> Note that Jersey only supports CDI as specified by JAX-RS
> 1.1 for EE 6.
I think CDI/weld is going to be VERY popular in the Java SE world as well. It is VERY attractive to be able to use the same solution for both web apps and applications. In my case I have an application that can work standalone AND as a war file (like Hudson as a famous example). So in my case using CDI/weld in both standalone SE and in a JEE 6 war file is a no-brainer (and alas, the ONLY thing that is not working in both worlds is ..... Jersey!).
> 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?
> 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.
> 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 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.
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. 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 ?
> 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.
> 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.
> 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). Instead you should react on the presense of "beans.xml" like Weld and assume that all beans are mananged by CDI/weld if present.
Thamks,
Morten