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 am able to build a WAR (via Maven) and deploy to my local Win 64 version of Tomcat (apache-tomcat-7.0.14-windows-x64), startup and access my program just fine.
I take the same WAR to an implementation of Tomcat on Win 32 (apache-tomcat-7.0.2), which is our actual remote server implementation and I get the following error during startup:
The log file stack trace error reports:
What little information I was able to find in web search suggested to add the listener to the web.xml file. I did that like so:
Despite the stack trace above, Tomcat prints the following info after it parses this part of the web.xml file:
So, on the one hand, Tomcat can't find ConfigureListener but on the other, it finds it too many times and in either case it's not deploying my WAR... I never asked for a reference to ConfigureListener, have no idea what that is or why I should care and what I read about it on-line is not helping me solve this problem that jumped up out of nowhere.
Thanks to anyone who can help me move past this and understand where I went wrong.
The ConfigureListener class is part of the JavaServer Faces environment and getting the "already configured" message is normal (although irritating). Getting a "Class Not Found" for it, is, however, fatal.
It would be well to examine the catalina.out file further to see what happened after the "already configured" message displayed, since at that point, the app is well on the way to deployment. Also look into the localhost log file, since occasionally something critical shows up there, instead of catalina.out.
It sounds like maybe this class was integrated into Tomcat7, but I wasn't aware that Tomcat7 was supposed to have built-in JSF. Then again, I'm so busy these days that Tomcat7 is still on the "future to-do" list.
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: May 25, 2011
Thanks for the help! I did not fully resolve this question but I did fix it. I compared the lib of my local Tomcat to the lib of the server's Tomcat and made sure that they pretty well matched (added servlet, xerces, j2ee and jsf jars). Tomcat now starts up and handles requests.
From what I see from searching around, this problem is caused by making one of the aforementioned a dependency in a Maven build. What I found is that you should only make those compile time and never run time dependencies. I checked and every time I mention those dependencies in my POM, they are compile time so that did not help me. The second solution is to start filling up the container's \lib dir and keep your fingers crossed....
Sounds like you made the common mistake of including j2ee jars in your WAR, which causes classpath conflicts with the j2ee classes in Tomcat itself. The jsp and servlet API jars should be marked as "provided" in a maven pom. In Tomcat6 and later, so should the EL jar. In full-stack j2ee servers, the jsf-impl jar is also provided by the server, but in Tomcat it is not, so you have to give it "compile" scope instead.
Joined: May 25, 2011
I did in fact ensure that the dependencies in question are listed as compile time only in the POM. However... I checked in \resources under the server project portion of my WAR and found that there was a reference to j2ee in there (not in the POM but on the build path). That must have been what was causing the problem. I removed that and then all my javax.mail classes blew up so I added the actual mail.jar. At least now I know where to look if I ever have this problem again.