So I'm new to JSF and CDI, but not all that new to Spring. I'm reading all sorts of online tutorials. Some of them just use "plain old JSF". Some show you how to replace JSF's managed container, with Spring's. And others talk about JSF, CDI and the "JSR 299 fiasco".
My question is a bit fuzzy, architectural, hand-wavy... I just don't have a firm grasp on the subject matter, I think.
If I'm using JSF and choose to use the CDI annotation (use the JEE CDI container, rather than the 'smaller, less capable' JSF container), then why would I use Spring? Aside from "I like Spring", and "the tutorial showed me how to do it" and "because I can". Is there a *need* to use Spring, if I'm using the move powerful CDI container ?
As for a reason I could imagine an existing Spring context file where you would want to reuse this within your application. Also, though I do not have enough experience to know which classes this might be, there are Spring classes that you would want to use and could not be integrated without having the Spring context.
Finally, a reason for having spring might be using AOP constructs for a cross cutting concerns and not covered by CDI.
I would love to hear from anyone with enough experience with CDI and Spring who can add to this conversation and expound on their experience.
That link... is it just me, or does that look pretty hackish to you? Like "forcing" two things together, and for what good reason?
Assuming I'm green fields, and don't particularly "require" anything from the spring framework (or so I suppose)... JSF with CDI... doesn't *need* Spring, right?
It seems to me, like much of the arguments in favour of using Spring's container as the bean manager for JSF, are based on JSF's default container being "weak" in comparison to Spring. And I might even agree with that, but that was all before CDI. But *if* I switch to using CDI... do the arguments go away, or merely change? Are there other reasons for still preferring to use Spring (that is: *don't* use JSF+CDI, use JSF+Spring and *not* CDI, and these are the reasons why...)
Yes, I guess it could be considered hackish if it is a solution not standard in one or the other framework so you are correct.
Read this about CDI and Spring http://java.dzone.com/articles/why-cdi-won%E2%80%99t-replace-spring. I think, at least for me, shows why you may want CDI and Spring in a single application. Granted, I realize normal architectural principles would make it seem not likely you have your JMS code and JSF code in different layers. But, I have done exactly as shown in the link. I had my Web application using JSF for the presentation and portion of its backend functionality involved posting to a JMS queue. As the author states, Spring makes using JMS almost trivial compared to the alternative.
So is this a reason (or use case) where you would use CDI and Spring together?
I really wish someone could jump in who has gone down this route but any users of CDI I have talked to have started using it now and were not users of Spring anyway so they are not having the conflict we are having!
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com