The reason that you had to do that is because Tomcat does not implement the full JEE spec. You would not include the JSF jars if you were running JBoss AS 5, for example even though it uses an embedded Tomcat. That's because JBoss is a full-stack JEE server and has its own JSF implementation classes built in, unlike stand-alone Tomcat.
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Oct 21, 2010
Ok, good to know. It's harder to find good information about getting a JSF project set up from the ground up, and almost impossible to find info on what to do if things go awry.
One of the best ways to get up and running quickly is to use a Maven archetype to generate the project. That will at least ensure that the basics are all there and in the right place. Maven can also generate the support files for some of the better-known IDEs while it's at it.
As the JSF standard firms up, we will gradually see the extra kinks that come from different server flavors and versions fade away and it can happen none too soon, as far as I am concerned.
Of course even then we have the issues that while JSF is designed to make things as simple as possible, the simplicity only works if one has a solid grounding in the basics of JSF - especially the JSF lifecycle and don't get trapped by outdated documentation pulled from the Internet. Too many people over-complicate their JSF code because they either don't understand basic HTTP request/response and the JSF lifecycle, don't realize that the more JSF-specific the code is, the more likely it's not done well, or because they (presumably) don't think that things could be that easy.