This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
As I known, Web JSF framework will add JSF 1.1 libraries to the J2EE 1.4 project if the target server doesn't provide any jsf implementation. And I do see 'JSF 1.1' and 'JSTL 1.1' libraries in the Project Libraries. It works for the Tomcat 5 that NetBeans 6 bundled before. Since Tomcat 5 is no longer bundled, I installed my Tomcat 5 I download from its official site. Create a Web JSF project and do see the 'JSF 1.1' and 'JSTL 1.1' libraries in the project. But when I try to deploy, I see the following error: The module has not been deployed. See the server log for details. If I copy the following files to $tomcat5_dir/common/lib, then it deploy good. But the project itself does not have 'JSF 1.1' and 'JSTL 1.1'. Looks like the auto-bundle JSF is not working! commons-beanutils.jar commons-collections.jar commons-digester.jar commons-logging.jar jsf-api.jar jsf-impl.jar jstl.jar
Created attachment 41665 [details] Tomcat 5.5 log
Created attachment 41666 [details] IDE message log
According to the attached IDE message log the web module was not deployed. So the exception in Tomcat 5.5 log are not result of missing jsf libraries, but of missing whole web application. IMHO the problem is somewhere in your Tomcat. Which version of the Tomcat 5.5 do you use? Could you send me by mail the zip file of your tomcat installation? And if you use no default BASDE_DIR, send me it as well.
Here is what I did: - download Tomcat 5.5 Core zip from (follow http://tomcat.apache.org/download-55.cgi) http://mirror.olnevhost.net/pub/apache/tomcat/tomcat-5/v5.5.23/bin/apache-tomcat-5.5.23.zip - unzip and update tomcat-users.xml - run NetBeans and add this Tomcat - create J2EE 1.4 web+JSF framework, I see both 'JSF 1.1' and 'JSTL 1.1' in project library. - deploy failed as described, this time I got different error (will attach) (same steps on NetBeans bundled Tomcat 5.5 works) - now I copy commons-*, jsf-api, jsf-impl, and jstl jars to $tomcat/common/lib - create J2EE 1.4 web+JSF and no 'JSF 1.1' and 'JSTL 1.1' as expect - deploy good this time My question: why do we add 'JSF 1.1' and 'JSTL 1.1' if the target server does not have JSF support, but we don't do the same for Java EE 5 (JSF 1.2) project? From my experiments, looks like we should never bundle this JSF RI in the project and make "copy JSF RI to users' servers" as a requirement. Then deployment compatibility issues should be less and more nature for real product deployment environment.
Created attachment 41756 [details] New Tomcat log
BTW, similar issues for Tomcat 5.5.17 and Tomcat 6.
I am getting the same problem. The workaround I found was not to copy the jars but to actually add a listener in the web.xml of the project. Once I add this to the web.xml of my application it works without even copying the jars to the $TOMCAT/common/lib folder: <listener> <listener-class>com.sun.faces.config.ConfigureListener</listener-class> </listener> Also there is a bug in Tomcat 5.5.20 and higher where the tomcat installation directory path should not have any spaces in it. If it has spaces the application does not work properly. Could that be the reason?
> - unzip and update tomcat-users.xml What did you add into tomcat-users.xml file? >- run NetBeans and add this Tomcat Did you start the Tomcat from NetBeans or from command line? >- deploy failed as described, this time I got different error (will attach) > (same steps on NetBeans bundled Tomcat 5.5 works) Was the application deployed correctly? There are two things the deployment and running. So which of them fails? From the second attachment it was the deployment. >My question: why do we add 'JSF 1.1' and 'JSTL 1.1' if the target server does >not have JSF support, but we don't do the same for Java EE 5 (JSF 1.2) project? Because in the JavaEE 5 specification is JSF 1.2 a part of the servlet container. The problem is that Tomcat 6 doesn't follow this specification. So it should be fixed as i wrote in issue #101689. Basically the rule is. If target server is JavaEE5 server do nothing else test whether on the classpath is a class from jsf. If the class is found do nothing else include jsf 1.1 and jstl 1.1 on the classpath. >From my experiments, looks like we should never bundle this JSF RI in the >project and make "copy JSF RI to users' servers" as a requirement. Then >deployment compatibility issues should be less and more nature for real product >deployment environment. I discussed this issue with many people from the real world:). Basically there are two groups. One wants to share such libraries on the server between applications, the second one wants to have the libraries only in the application, because then there are protected against incompatibility between different versions and every web module can use different version. So we shouldn't push to user to do this. For me this is working (I'm on Linux). And I haven't seen so far any evidence that this is caused by the jsf libraries.
yousufh, do you know the number of the bug. Could you put a link here?
here is the link to the tomcat bug I was talking about http://issues.apache.org/bugzilla/show_bug.cgi?id=40809
Yes, add <listener> does work. Should we fix it for M9 as a showstopper since we now no longer bundle Tomcat 5.5. Users will now download their own Tomcat and find this issue. Or we may start not bundle any JSF RI in the future and require users to add them to their servers. One RI in the server is much better than one RI in every project. As I'm thinking, adding JSF RI was helping NetBeans IDE development. Therefore, users don't need to do any server setup and try their webApp on the bundled Tomcat. But if we no longer bundle Tomcat, then this scheme looks not OK.
yousufh, thanks for the link. potingwu, and what you will do if there will be one application with my faces and second one with SUN RI? We shouldn't solve here the library deployment to the server, it's another issue.
> what you will do if there will be one application with my faces > and second one with SUN RI? We shouldn't solve here the library deployment to > the server, it's another issue. Do you mean 'adding <listener>' or 'adding JSF RI'? > Yes, add <listener> does work. Should we fix it for M9 as a showstopper since > we now no longer bundle Tomcat 5.5. Users will now download their own Tomcat > and find this issue. Anyway, do we want to add <listener> for M9 to prevent the issues we should get a lot leter.
FYI: I do not have this problem with Tomcat 5.5.17 (an externally added one). Application deploys and runs fine without adding any jars or editing the web.xml. I see this happening only when I deploy to Tomcat 5.5.23 or 6.
Yes, I just confirmed that no such issue for Tomcat 5.5.17 (NetBeans bundled before) but failed for Tomcat 5.5.23 and 6. Looks like it's more serious that it's very difficult for the current users; they will always download the latest one (never 5.5.17), and not easy to figure out the cause (when reporting bug, others will say work-for-me and then ...)
Not only Tomcat 5.5.23 and 6 but all versions of Tomcat from 5.5.20 and higher have this problem.
I have committed a fix, which resolves more issues at once, because there more things had to be rewritten: #115506 - HTTP Status 404 - Servlet Faces Servlet is not available #118344 - It is not possbile to deploy application with JSF to JBoss 4.0.4 #102544 - Cannot deploy JSF 1.1 web app to Tomcat 5 #106580 - JSF library missing on EE5 Projects for Weblogic It rewrites the handling of JSF libraries in the JSF configuration panel. It also resolves problem with different jsf versions and implementations. Solves better recognizing MyFaces implementation and JSF instalation folders. Rewrites creating and also handling already created JSF libraries in the IDE. Checking in web/jsf/src/org/netbeans/modules/web/jsf/Bundle.properties; /cvs/web/jsf/src/org/netbeans/modules/web/jsf/Bundle.properties,v <-- Bundle.properties new revision: 1.15; previous revision: 1.14 done Checking in web/jsf/src/org/netbeans/modules/web/jsf/JSFFrameworkProvider.java; /cvs/web/jsf/src/org/netbeans/modules/web/jsf/JSFFrameworkProvider.java,v <-- JSFFrameworkProvider.java new revision: 1.27; previous revision: 1.26 done Checking in web/jsf/src/org/netbeans/modules/web/jsf/JSFUtils.java; /cvs/web/jsf/src/org/netbeans/modules/web/jsf/JSFUtils.java,v <-- JSFUtils.java new revision: 1.4; previous revision: 1.3 done Checking in web/jsf/test/unit/src/org/netbeans/modules/web/jsf/xdm/model/faces-config-application.xml; /cvs/web/jsf/test/unit/src/org/netbeans/modules/web/jsf/xdm/model/faces-config-application.xml,v <-- faces-config-application.xml new revision: 1.3; previous revision: 1.2 done Checking in web/jsf/test/unit/src/org/netbeans/modules/web/jsf/xdm/model/JSFConfigModelTest.java; /cvs/web/jsf/test/unit/src/org/netbeans/modules/web/jsf/xdm/model/JSFConfigModelTest.java,v <-- JSFConfigModelTest.java new revision: 1.15; previous revision: 1.14 done Checking in web/jsf/test/unit/src/org/netbeans/modules/web/jsf/xdm/model/data/goldenfiles/JSFConfigModelTest/gold-application.xml; /cvs/web/jsf/test/unit/src/org/netbeans/modules/web/jsf/xdm/model/data/goldenfiles/JSFConfigModelTest/gold-application.xml,v <-- gold-application.xml new revision: 1.3; previous revision: 1.2 done Checking in web/jsf/src/org/netbeans/modules/web/jsf/wizards/JSFConfigurationPanelVisual.form; /cvs/web/jsf/src/org/netbeans/modules/web/jsf/wizards/JSFConfigurationPanelVisual.form,v <-- JSFConfigurationPanelVisual.form new revision: 1.11; previous revision: 1.10 done Checking in web/jsf/src/org/netbeans/modules/web/jsf/wizards/JSFConfigurationPanelVisual.java; /cvs/web/jsf/src/org/netbeans/modules/web/jsf/wizards/JSFConfigurationPanelVisual.java,v <-- JSFConfigurationPanelVisual.java new revision: 1.21; previous revision: 1.20 done Checking in web/jsf/src/org/netbeans/modules/web/jsf/wizards/Bundle.properties; /cvs/web/jsf/src/org/netbeans/modules/web/jsf/wizards/Bundle.properties,v <-- Bundle.properties new revision: 1.17; previous revision: 1.16 done Checking in web/jsf/src/org/netbeans/modules/web/jsf/wizards/JSFConfigurationPanel.java; /cvs/web/jsf/src/org/netbeans/modules/web/jsf/wizards/JSFConfigurationPanel.java,v <-- JSFConfigurationPanel.java new revision: 1.11; previous revision: 1.10 done Checking in j2ee/utilities/test/unit/src/org/netbeans/modules/j2ee/common/UtilTest.java; /cvs/j2ee/utilities/test/unit/src/org/netbeans/modules/j2ee/common/UtilTest.java,v <-- UtilTest.java new revision: 1.4; previous revision: 1.3 done Checking in j2ee/utilities/src/org/netbeans/modules/j2ee/common/Util.java; /cvs/j2ee/utilities/src/org/netbeans/modules/j2ee/common/Util.java,v <-- Util.java new revision: 1.19; previous revision: 1.18 done