Websphere 8.0 Installation Guide

MyFaces 2.0 is now the default implementation with WebSphere Application Server v8 and is supported out of the box - no extra configuration needed. WAS v8 still comes with the JSF Reference Implementation(RI) version 1.2 that can be configured using admin commands or directly from the admin console. Both MyFaces 2.0 and the JSF 1.2 RI are supported as first class OSGi runtime bundles. You can package your own user-supplied version of MyFaces as a Shared Library or add the jars directly to your WEB-INF/lib, as stated in the WebSphere v7.0 instructions.

Websphere 7.0 Installation Guide

Starting with Websphere 7.0, both the JSF Sun RI and a version of Myfaces are both shipped as part of the WAS runtime, with the ability provided to choose which implementation to use for your application after installation. The following steps will detail how to use the implementation shipped with WAS. It is still possible to use a user-supplied version of the MyFaces bundles. If you are trying to use a user-supplied version of MyFaces 2.0, there are special steps that need to be taken for annotation and injection support. Please see the section on using Using a user-supplied version of MyFaces 2.0.x with WebSphere Application Server v7.0.

Using the WebSphere Application Server v7.0 supported MyFaces implementations

1. Deploy the web application on WAS.

2. Execute the command to change the runtime from Sun RI to MyFaces.

This can be done either via the WAS admin console or through a wsadmin command.

3. Start your application.

Using a user-supplied version of MyFaces 2.0.x with WebSphere Application Server v7.0

As of WebSphere Application Server, MyFaces 2.0 annotation providers are included as part of the WAS optionalLibraries. A developerWorks article will be available soon with instructions on how to configure these providers. Until that developerWorks article is posted, follow the instructions outlined from this article.

Websphere 6.1 Installation Guide

Unlike Websphere 6.0, in Websphere 6.1 the JSF Sun RI is bundled together with several other WAS libraries in com.ibm.ws.webcontainer_2.0.0.jar, so removing the webspheres JSF API jars is not an option. The procedure below describes how to use MyFaces, TOMAHAWK (and even Tiles) on Websphere 6.1 by altering the module classloader policy to load classes using the application class loader first (thereby loading the MyFaces jars before the Sun RI jars). This procedure has been tested with MyFaces 1.1.3, TOMAHAWK 1.1.3, and Websphere

1. Copy the MyFaces JSF jars and dependencies to WebApp lib (follow step 1 of the Websphere 6.0 Installation Guide without removing IBM jars below).

Make sure you do NOT copy commons-logging-1.0.4 jar (conflicts with the commons-logging jar already provided by Websphere) and also jsp-2.0.jar (which will cause a "com.ibm.ws.jsp.taglib.TldParser logParseErrorMessage: The JSP container failed to load the TagExtraInfo class" exception with JSF applications that use tiles).

2. Deploy the web application on WAS.

3. Alter the module classloader policy to application first.

Note that there are several ways to set the classloader policy in websphere (at the server, application, and module level). You need to set it at the module level as follows: Click on Enterprise Applications > Your application > Manage Modules > Your war file > Change Class loader order to "Classes loaded with application class loader first"

4. Start your application.

If the extension-Filter does not work properly, it might help to set the property com.ibm.ws.webcontainer.invokefilterscompatibility=true. Instructions can be found at this IBM support site.

Websphere 6.0 Installation Guide

****Please note that removing any of the jars from the WebSphere lib directory as described in these instructions is unsupported by IBM. If you wish to maintain support you can use the alternate WebSphere 6.0 instructions below that do not remove the IBM jars ****

1. Remove Webspheres JSF API and Implementation

Remove Jsf API and Jsf Impl from Webshpere AppServer/lib dir

  • AppServer/lib/jsf-api.jar - remove

  • AppServer/lib/ws-jsf.jar - remove

2. Copy the MyFaces JSF API to WAS

Copy the MyFaces API to AppServer/lib dir

  • myfaces-api.jar - copy to AppServer/lib

3. Add commons classes to WAS

Copy commons classes to AppServer/lib dir

  • commons-beanutils.jar
  • commons-codec.jar
  • commons-collections.jar
  • commons-digester.jar
  • commons-lang.jar

For library versions see Library dependencies

4. Remove MyFaces API from your web archive

  • myfaces-api.jar - remove from war

5. Deploy web application on WAS

Nothing special here, just use Classloader option "Parent first"

6. Optional / untested

You may also add the MyFaces Jsf Implementation myfaces-impl.jar to the AppServer/lib dir. It should work with MyFaces Core >= 1.1.2

Attention: Do not copy a myfaces-impl to AppServer/lib dir that depends on the old myfaces-commons library.
Reason: Classloader problems may show up, when MyFaces-Impl and MyFaces-Tomahawk reference different myfaces-commons.jar versions.
In MyFaces 1.1.2 the commons project was refactored and is now called shared.
The shared classes are part of both myfaces-impl and myfaces-tomahawk. To avoid classloader problems due to different versions of shared classes the package names are different for impl and tomahawk.

Websphere 6.0 Installation Guide (without removing IBM jars)

This is a simple procedure to use MyFaces, TOMAHAWK (and even ADF Faces) on a Websphere 6 webapp just using its "PARENT_LAST" property. This procedure is being tested without any problem until now on a Websphere BASE o0444.14. This requires access to the internet, because the ibm implementation of JSF tries to resolve the faces-config.xml dtd This, however, can be circumvented by replacing all references to web-facesconfig_1_1.dtd with a reference to web-facesconfig_1_0.dtd. For example, a faces config like this:

<!DOCTYPE faces-config PUBLIC "-//Sun Microsystems,
Inc.//DTD JavaServer Faces Config 1.1//EN" "http://java.sun.com/dtd/web-facesconfig_1_1.dtd">

must be replaced as follows:

<!DOCTYPE faces-config PUBLIC "-//Sun Microsystems,
Inc.//DTD JavaServer Faces Config 1.0//EN" "http://java.sun.com/dtd/web-facesconfig_1_0.dtd">

1. Copy the MyFaces JSF jars and dependencies to WebApp lib

Copy jars to ${WebApp}/WEB-INF//lib dir

  • MyFaces & Tomahawk

  • myfaces-api-1.1.3.jar
  • myfaces-impl-1.1.3.jar
  • tomahawk-1.1.2.jar

2. Deploy web application on WAS

Use Classloader option "Parent last"

Websphere 5.1.X Installation Guide

1. Use Classloader option "Parent last"

2. List of files in WAR's lib, some files may not be needed, but it works for me.

  • antlr-2.7.6rc1.jar
  • cglib-nodep-2.1_2.jar
  • commons-beanutils-1.7.0.jar
  • commons-codec-1.3.jar
  • commons-collections-3.1.jar
  • commons-digester-1.6.jar
  • commons-el-1.0.jar
  • commons-lang-2.1.jar
  • dom4j-1.6.1.jar
  • ehcache-1.1.jar
  • el-api-1.0.jar
  • el-ri-1.0.jar
  • hibernate-3.1.2.jar
  • jsfExt.jar
  • jsf-facelets-1.1.11.jar
  • jstl-1.1.0.jar
  • myfaces-api-1.1.3.jar
  • myfaces-impl-1.1.3.jar
  • ojdbc14.jar
  • oscache-2.3.1.jar
  • portals-bridges-common-1.0.jar
  • portals-bridges-frameworks-1.0.jar
  • portals-bridges-jsf-1.0.jar
  • portals-bridges-portletfilter-1.0.jar
  • spring-1.2.6.jar
  • tagHandlers.jar
  • tomahawk-1.1.5-SNAPSHOT.jar
  • tomahawk-sandbox-1.1.5-SNAPSHOT.jar
  • jsp-api.jar

3. Use pluto to test first, but needs to remove jsp-api.jar for pluto.

use "org.apache.portals.bridges.jsf.FacesPortlet" bridge instead of "org.apache.myfaces.portlet.MyFacesGenericPortlet" to work with pluto. (inside portlet.xml)

Websphere_Installation (last edited 2012-01-28 00:41:08 by 167)