Hello,
Just like rdean400, we are also running JSF 2.0 on WAS 7, and I can confirm that it *mostly* work.
The problem with jsf.js is more like a global problem of resource access, as I'll depict in the following.
My company is currently looking forward to use JSF 2.0 in production, while keeping their currently running servers, i.e. using Websphere Application Server 7.
Here is a simple test program that illustrates the problem more deeply, but doesn't gives us any hints on how to solve it.
Were are using the following tools :
- Maven 2.2.1
- WAS 7.0.0.7 and WAS 7.0.0.5
- JSF 2.0.2 RI (Mojarra 2.0.2 (FCS b10))
- The EL version shipped with WAS 7 is sufficient for that test, but we are using version 2.2 for development.
- using WAS PARENT_LAST configuration for WAR and EAR deployment classloader. The module loader is also set to PARENT_LAST.
In the given test case, the following piece of log indicates that Mojarra is indeed loaded with the application startup :
[24/02/10 17:02:49:258 CET] 0000001b config I Initialisation de Mojarra 2.0.2 (FCS b10) pour le contexte '/Prototype-test'
The test project is architectured as follow, using three subprojects :
- A project (components-projectTest folder) for the components (only one in that case) with the following files :
* META-INF\resources\projectTest\composantTest.xhtml which is the component's code
* A class com\project\portailvalorisation\components\ComposantTestBean.java used by the component
* META-INF\faces-config.xml
* META-INF\projecttest.taglib.xml
- A project for generating the web application, using the component defined below.
* The component is thus packaged as a JAR in the WEB-INF\lib folder.
* The index.xhtml page is using the component.
- An EAR project for deploying the application directly to WAS, preconfigured. That project takes care of setting the PARENT_LAST properties.
This is a standard configuration AFAIK, and we tested that project successfully on JBoss 6.0.0.M2 and Glassfish v3 without problems.
The problem we encounter with WAS 7 is the same that the one encountered with jsf.js, the components resources cannot be accessed, i.e. the namespace resolves correctly regarding to the component, but the xhtml page cannot be found.
If we explode the component's JAR content from WEB-INF/lib into our WAR, the resources can then be found (but then the java classes are misplaced), and we can use the application as expected. It is important to understand that within the JAR file, the other files can still be found, for instance xml configuration files, java classes. The problem only occurs with resources (XHTML, CSS...).
What happens here is that when the content of the JAR is exploded into the WAR, the ressources are relocated in the META-INF\resources folder of the root webapp project, and thus made accessible.
Here is a complete execution log of the project startup from WAS 7 (in french, sorry, i can translate if needed) :
[24/02/10 17:02:48:430 CET] 0000001b AdminHelper A ADMN1009I: Tentative de démarrage de l'application Prototype_1.0.0.
[24/02/10 17:02:48:462 CET] 0000001b CompositionUn A WSVR0190I: Démarrage de l'unité de composition WebSphere:cuname=Prototype_1.0.0 dans l'application BLA WebSphere:blaname=Prototype_1.0.0.
[24/02/10 17:02:49:087 CET] 0000001b ApplicationMg A WSVR0200I: Lancement de l'application Prototype_1.0.0
[24/02/10 17:02:49:087 CET] 0000001b ApplicationMg A WSVR0204I: Application : Prototype_1.0.0 Niveau de compilation d'application : Inconnu
[24/02/10 17:02:49:118 CET] 0000001b ResourceMgrIm I WSVR0049I: Liaison de DefaultEJBTimerDataSource en tant que jdbc/DefaultEJBTimerDataSource
[24/02/10 17:02:49:149 CET] 0000001b webapp I com.ibm.ws.webcontainer.webapp.WebGroupImpl WebGroup SRVE0169I: Chargement du module Web : Prototype-test-1.0.0.war.
[24/02/10 17:02:49:165 CET] 0000001b WASSessionCor I SessionContextRegistry getSessionContext SESN0176I: Un nouveau contexte de session va être créé pour la clé d'application default_host/Prototype-test
[24/02/10 17:02:49:258 CET] 0000001b config I Initialisation de Mojarra 2.0.2 (FCS b10) pour le contexte '/Prototype-test'
[24/02/10 17:02:49:790 CET] 0000001b application I JSF1048 : Présence d''annotations PostConstruct/PreDestroy Les méthodes de beans gérés marquées avec ces annotations auront des annotations dites traitées.
[24/02/10 17:02:50:133 CET] 0000001b config I Monitoring file:/C:/Program Files/IBM/SDP/runtimes/base_v7/profiles/was70profile1/installedApps/CL-CL06Node02Cell/Prototype_1.0.0.ear/Prototype-test-1.0.0.war/WEB-INF/faces-config.xml for modifications
[24/02/10 17:02:50:149 CET] 0000001b servlet I com.ibm.ws.webcontainer.servlet.ServletWrapper init SRVE0242I: [Prototype_1.0.0] [/Prototype-test] [Faces Servlet] : L'initialisation a abouti.
[24/02/10 17:02:50:149 CET] 0000001b webcontainer I com.ibm.ws.wswebcontainer.VirtualHost addWebApplication SRVE0250I: Module Web null lié à default_host[*:9081,*:80,*:9444,*:5063,*:5062,*:443].
[24/02/10 17:02:50:149 CET] 0000001b ApplicationMg A WSVR0221I: L'application est lancée : Prototype_1.0.0
[24/02/10 17:02:50:149 CET] 0000001b CompositionUn A WSVR0191I: L'unité de composition WebSphere:cuname=Prototype_1.0.0 dans l'application BLA WebSphere:blaname=Prototype_1.0.0 a démarré.
[24/02/10 17:02:58:540 CET] 00000021 lifecycle I JSF1027 : [/Prototype-test] Les objets ELResolvers de JSF n'ont pas été enregistrés avec le conteneur JSP.
[24/02/10 17:02:58:587 CET] 00000021 context W JSF1091 : Aucun type mime détecté pour le fichier composantTest.xhtml. Pour résoudre ce problème, ajoutez un mappage mime-type au fichier web.xml de l'application.
[24/02/10 17:02:58:587 CET] 00000021 application W JSF1064 : Impossible de localiser ou de servir une ressource, composantTest.xhtml, depuis la bibliothèque projectTest.
Please note the last error JSF1064 indicating that the xhtml resource can't be found. This error is generated when we try to access the index.xhtml page.
The JSF page produced displays the following error :
/index.xhtml @15,32 <projectTest:composantTest> Tag Library supports namespace:
http://www.project.com/projectTest, but no tag was defined for name: composantTest
To compile the project, please use the
mvn -P WAS7 clean install
command for replicating the described error, and
mvn -P WAS7Bypass clean install
to make it work by exploding the JAR content.
The example normal behavior is to display the string "If you see this message, the Test component is working". To compile a war for Glassfish v3, just use the JBoss6 maven profile, and deploy the WAR (the EAR is still specific to WAS7).
Activating the JSF log from WAS 7 doesn't indicate any other error (finest on javax.enterprise.resource.webcontainer.jsf.*), while displaying many more information.
This is really a critical problem for us, determining the possible adoption of the technology, since it prevents us from testing and deploying easily our code (we have to explode our components manually into our WAR (using the maven-dependency-plugin) which is incompatible with the debugging process of RAD7.5, our IDE).
Please tell me if you need any more information.
The source code is available at
http://dl.free.fr/pFNMYGoBT (If its written in french please click on 'Télécharger ce fichier' which translates to 'Download that file').
Olivier COUPELON
[Message sent by forum member 'coupelon' (olivier.coupelon_at_wanadoo.fr)]
http://forums.java.net/jive/thread.jspa?messageID=388484