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.

Bug 102544 - Cannot deploy JSF 1.1 web app to Tomcat 5
Summary: Cannot deploy JSF 1.1 web app to Tomcat 5
Status: RESOLVED FIXED
Alias: None
Product: serverplugins
Classification: Unclassified
Component: Tomcat (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: Petr Pisl
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-04-25 20:40 UTC by _ potingwu
Modified: 2007-10-11 22:12 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Tomcat 5.5 log (22.89 KB, text/plain)
2007-04-25 20:40 UTC, _ potingwu
Details
IDE message log (9.51 KB, text/plain)
2007-04-25 20:41 UTC, _ potingwu
Details
New Tomcat log (11.19 KB, text/plain)
2007-04-26 17:50 UTC, _ potingwu
Details

Note You need to log in before you can comment on or make changes to this bug.
Description _ potingwu 2007-04-25 20:40:07 UTC
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
Comment 1 _ potingwu 2007-04-25 20:40:41 UTC
Created attachment 41665 [details]
Tomcat 5.5 log
Comment 2 _ potingwu 2007-04-25 20:41:19 UTC
Created attachment 41666 [details]
IDE message log
Comment 3 Petr Pisl 2007-04-26 15:13:01 UTC
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. 
Comment 4 _ potingwu 2007-04-26 17:49:01 UTC
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.
Comment 5 _ potingwu 2007-04-26 17:50:37 UTC
Created attachment 41756 [details]
New Tomcat log
Comment 6 _ potingwu 2007-04-26 17:57:28 UTC
BTW, similar issues for Tomcat 5.5.17 and Tomcat 6.
Comment 7 Yousuf Haider 2007-04-26 18:01:48 UTC
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?
Comment 8 Petr Pisl 2007-04-26 18:12:33 UTC
> - 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. 
Comment 9 Petr Pisl 2007-04-26 18:13:57 UTC
yousufh, do you know the number of the bug. Could you put a link here?
Comment 10 Yousuf Haider 2007-04-26 18:20:29 UTC
here is the link to the tomcat bug I was talking about
http://issues.apache.org/bugzilla/show_bug.cgi?id=40809
Comment 11 _ potingwu 2007-04-26 18:21:13 UTC
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.
Comment 12 Petr Pisl 2007-04-26 18:34:31 UTC
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. 

 
Comment 13 _ potingwu 2007-04-26 18:59:50 UTC
> 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.
Comment 14 Yousuf Haider 2007-04-27 18:13:03 UTC
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.
Comment 15 _ potingwu 2007-05-11 17:40:18 UTC
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 ...)
Comment 16 Yousuf Haider 2007-05-11 17:56:36 UTC
Not only Tomcat 5.5.23 and 6 but all versions of Tomcat from 5.5.20 and higher
have this problem.
Comment 17 Petr Pisl 2007-10-11 22:12:09 UTC
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