This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I just stumbled on this old thread. Sorry for resurrecting a Zombie thread at CodeRanch.
So, I clearly took the reference to Java EE 5 too literally. When they say 'based on' they're clearly not talking about every part of the API, but really just the web container parts of the specification.
Still, it seems every good book on JSF out there discusses CDI, Contexts and Dependency Injection, and CDI isn't part of the Servlet and JSP specification. I'm guessing that I can't leverage CDI in my JSF applications and deploy to say, Tomcat 7, because Tomcat 7 is simply a web container? Looks like I have more work to do.
I agree with everything you say in your last posts. JSF does work in Web containers that do not support J2EE fully. And Tomcat 7 does not support CDI fully (only parts of it) so I would not use CDI with Tomcat (but I do not know what the Tomcat developers plan to do in the future so although not a full J2EE container it may support CDI in future versions.)
I do believe there is a project that is working on building a Java EE container on top of Tomcat.
All the books on JSF 2.0 use CDI. This makes it pretty frustrating if you're interested in deploying directly to Tomcat. I wonder if adding in CDI support to Tomcat 7 is as simple as just adding in a JAR or two?
Ooops...I see that your second article by Cay talks about this precisely.
"this may be the time for switching to GlassFish."
That's a pretty sad statement, to suggest to do proper JSF 2.0 develoment that we should abandon Tomcat.
Joined: Apr 15, 2008
Yeah, I for one will not move to J2EE containers so I just do not use CDI. Cay is obviously a hardcore J2EE container supporter.
But people are free to do as they wish...
Cameron Wallace McKenzie
author and cow tipper
Similarly, without a beans.xml file, I more often than not saw this error too:
Target Unreachable, identifier resolved to null
So, just by putting a blank beans.xml file into the WEB-INF folder seemed to fix it.
By the way, one other problem I had was constantly getting a 404 error message when I ran the program. A few weird things happened. First off, I didn't make my POJO serializable, so make sure your JavaBean implements java.io.Serializable.
I also had a Named and SessionScope class files compiled, created and placed in my classes directory. I have no idea what happened, but I deleted them. After deleting them and implementing java.io.Serializable, things worked. Strange.
Joined: Apr 15, 2008
That is what he says yes. Altough it does not necessarily mean that it actually works. Or that it should be done (what is for example the performance impact and so on). And of course the article is old so the situation might have changed.
But if you actually test it with real-life application I would like to hear the results you get