The adjustments and limitations for getting the sample portlets (Chat and Location) running on WebSphere Portal 7 are as follows:

a) Using WebSphere Portal V7 on ICEfaces EE 1.8.2 P03 requires a change to the header in the web.xml namespace. The required header is as follows:

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
version="2.5">

Once this is in things should work just fine.

b) There is currently a limitation with regards to RAD v 7.5.4 that requires portlets be deployable manually via the WebSphere Portal Administrative Console. At present portlets cannot be deployed directly from Rational Application Developer (RAD) v 7.5.4 This has to do with the way that the IDE's project-level JSF facets automatically inject additional configurations at deployment time and require the portlet to reside in an EAR. Once they deploy it appears the JSF versions are changed. All attempts to work around the JSF version problem using parent-last classloading and isolated library techniques documented in support of JSF 2.0 portlets / applications running on WebSphere have been unsuccessful. So until the issue can be resolved by IBM, portlet deployment must be handled through the administrative console.

After doing my own testing, the two sample portlets appear to work properly. The following are additional observations:

• As noted in the email, I used the Admin Console to deploy the two portlets - Chat and Location. Both appeared to work fine for me on 4 different browsers.

• Our 1.8 repository doesn't currently have a build target for WebSphere Portal 7. We'll need to do this to aid in QA testing as well as allowing customers to be able to build the examples from the release.

• While the Chat and Location portlets are provided as simple portlet examples, the Component Showcase can also be built for portlets and provides a much broader coverage of the component suite running on the portal. Once we have a viable build target, we should be able to generate and test this from the repository.

• Looks like the icesoft_locationportlet_war.war currently has an extra copy of "locaion.war" bundled up inside it. While this has no functional impact, it does make the .war bigger than it needs to be.

• In the test portlet on the FTP server, it looks like the license header is missing from web.xml. If we plan to publish these and make them generally available, that should probably be restored. I only saw this because I was checking the required edit for the namespace and I didn't do a comprehensive check of all the files.

The version of JSF that is included with WebSphere Portal Server (WPS):

1.2_07-b03-FCS

is a bit older than the library we include with the current ICEfaces 1.8 distribution:

1.2_15-b01-FCS

I had all kinds of problems trying to get WPS to use our versions of the libs - both shared library or PARENT_LAST classloading techniques. I'd frequently get the following when starting up when I included the libs myself:

[3/30/12 13:09:29:970 PDT] 0000007e config W JSF1056: Unable to create InputSource for URL 'wsjar:file:/C:/IBM/WebSphere/wp_profile/installedApps/icesoftpc/compshow.ear/component-showcas.war/WEB-INF/lib/jsf-impl-1.2.jar!/com/sun/faces/web-facesconfig_1_1.dtd'.

After trying for hours to come up with the correct combination of settings, I reverted to just use the version that came with WebSphere. The portlets mostly seem to work with this setup although I did see this in the log which may have occurred when the session expired:

[3/30/12 14:14:12:979 PDT] 00000037 webapp E com.ibm.ws.webcontainer.webapp.WebApp logServletError SRVE0293E: [Servlet Error]-[Blocking Servlet]: java.lang.IllegalStateException
at com.ibm.ws.session.http.HttpSessionImpl.getAttributeNames(HttpSessionImpl.java:214)
at com.ibm.ws.session.SessionData.getAttributeNames(SessionData.java:178)
at com.ibm.ws.session.HttpSessionFacade.getAttributeNames(HttpSessionFacade.java:154)
at com.sun.faces.application.WebappLifecycleListener.syncSessionScopedBeans(WebappLifecycleListener.java:317)
at com.sun.faces.application.WebappLifecycleListener.requestDestroyed(WebappLifecycleListener.java:87)
at com.sun.faces.config.ConfigureListener.requestDestroyed(ConfigureListener.java:241)
at com.ibm.ws.webcontainer.webapp.WebApp.notifyServletRequestDestroyed(WebApp.java:1937)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:1180)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:502)
at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:179)
at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:91)
at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:864)
at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1583)
at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:186)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:445)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest(HttpInboundLink.java:504)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest(HttpInboundLink.java:301)
at com.ibm.ws.http.channel.inbound.impl.HttpICLReadCallback.complete(HttpICLReadCallback.java:83)
at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:165)
at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161)
at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:138)
at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:204)
at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:775)
at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:905)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1563)

C:\IBM\WebSphere\wp_profile\logs\ffdc\WebSphere_Portal_63e263e2_12.03.30_14.14.12.9482067136851783147374.txt

Google Maps didn't work for me and there were some errors in the client console that suggest it's related to the opaque URLs that WebSphere Portal uses:

ice-extras.js:28Uncaught ReferenceError: GMap2 is not defined

:10039/wps/myportal/Home/ice1comp02/!ut/p/b1/pY_NCoMwEISfxSfIJub3GAyJgVDSFmnNpeQkgtpL6fPX2rPx0LktM98sgxLqJSaUEywVuqO05Pc45Nf4XPL0vRN_AI91DA2j1CoB3vDIDVACHVsD_RponG6pCACSSQxet53gV0PgTDd-x3YByry7QJE_HfLkLx50fbT_hlLpxdbw69iRBjSnyVqr_KCr6gO4SFxp/:531
Uncaught SyntaxError: Unexpected token &

:10039/wps/myportal/Home/ice1comp02/!ut/p/b1/pY_NCoMwEISfxSfIJub3GAyJgVDSFmnNpeQkgtpL6fPX2rPx0LktM98sgxLqJSaUEywVuqO05Pc45Nf4XPL0vRN_AI91DA2j1CoB3vDIDVACHVsD_RponG6pCACSSQxet53gV0PgTDd-x3YByry7QJE_HfLkLx50fbT_hlLpxdbw69iRBjSnyVqr_KCr6gO4SFxp/:540
Uncaught SyntaxError: Unexpected token &

So the summary was that I was able to get most portlets to work with the built-in JSF implementation supplied with WPS but unable to get it to work with our implementation yet.

To further summarize, I tried the following techniques to run ICEfaces 1.8.x on WebSphere Portal 7:

1) Include the JSF 1.2 libs that we release with ICEfaces in the .war file and set parent classloading to FIRST

Result: It appears to make an attempt to use the JSF jars included in the .war file:

[4/2/12 10:08:05:208 PDT] 00000043 config I Initializing Mojarra (1.2_15-b01-FCS) for context '/wps/icecompshow'

but has trouble processing a DTD file:

[4/2/12 10:08:05:317 PDT] 0000008e config W JSF1056: Unable to create InputSource for URL 'wsjar:file:/C:/IBM/WebSphere/wp_profile/installedApps/icesoftpc/icecompshow.ear/component-showcas.war/WEB-INF/lib/jsf-impl-1.2.jar!/com/sun/faces/web-facesconfig_1_1.dtd'.

...

[4/2/12 10:08:17:548 PDT] 00000043 webapp E com.ibm.ws.webcontainer.webapp.WebApp notifyServletContextCreated SRVE0283E: Exception caught while initializing context:

com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! Unexpected end of file from server
at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:214)
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:200)

...

Caused by: java.net.SocketException: Unexpected end of file from server
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:770)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:633)
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:767)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:633)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1067)
at org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown Source)
at org.apache.xerces.impl.XMLEntityManager.startEntity(Unknown Source)
at org.apache.xerces.impl.XMLEntityManager.startDTDEntity(Unknown Source)
at org.apache.xerces.impl.XMLDTDScannerImpl.setInputSource(Unknown Source)
at org.apache.xerces.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source)
at com.sun.faces.config.ConfigManager$ParseTask.getDocument(ConfigManager.java:445)
at com.sun.faces.config.ConfigManager$ParseTask.call(ConfigManager.java:415)
at com.sun.faces.config.ConfigManager$ParseTask.call(ConfigManager.java:372)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:315)
at java.util.concurrent.FutureTask.run(FutureTask.java:150)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:736)

2) Include the JSF 1.2 libs that we release with ICEfaces in the .war file and set parent classloading to LAST

Seems to do the same as #1 above.

The only apparently relevant information I could find is this bug report which was dismissed as unrelated to Eclipse and BIRT which makes sense as it's a WebSphere + JSF issue.

3) Do not include the JSF 1.2 libs that we release with ICEfaces but instead, set up a shared library of those jars and associate it with the application.

The initial deploy doesn't complain because it simply tries to use the built-in JSF to start up the application:

[4/2/12 11:21:24:064 PDT] 0000007d config I Initializing Sun's JavaServer Faces implementation (1.2_07-b03-FCS) for context '/wps/icecompshow'

To associate the shared library, you have to use the server admin (as opposed to the portal admin) but once that is done and the app restarts, I get the same issue as #1 and #2 above. On a hunch, I replaced the current version of JSF that we deploy with ICEfaces with the latest JSF 1.2 from the Mojarra just in case there was a possible corruption but the results were the same. I checked that the file indicated in the URL existed on the filesystem ('wsjar:file:/C:/IBM/WebSphere/wp_profile/installedApps/icesoftpc/icecompshow.ear/component-showcas.war/WEB-INF/lib/jsf-impl-1.2.jar!/com/sun/faces/web-facesconfig_1_1.dtd') and it does. So I'm at a loss to explain the problem.

4) In the end, the only way I could get it to work was to not include the JSF 1.2 libs that we release with ICEfaces and simply use the version of JSF 1.2 that is supplied with WebSphere Portal with the caveat being that the version of JSF supplied is a bit older than what we support in the release.

I tried a couple of more off-the-wall suggestions that I gleaned off the web. First, as per a note in the MyFaces Wiki:

http://wiki.apache.org/myfaces/Websphere_Installation

suggests trying to change the DOCTYPE of the faces-config.xml files to specify 1.0 rather than the 1.1 DTD. That didn't appear to work so also tried the strategy from the following blog entry:

http://www.jroller.com/holy/entry/jsf_nullpointerexception_at_facesservlet_init

The suggestion here was to get a copy of the DTD and include it in the WEB-INF directory then adjust the DOCTYPE to load is locally. That didn't work either. At this point, I'm out of things to try/recommend.

Using the built-in JSF libraries supplied with WebSphere Portal 7 (using latest trunk of P04 for testing), I ran all the portlets in the showcase and found the following:

Google Maps
Fails as previously documented above.

Tabset Dynamic
The tab content is not rendered properly. See screenshot.

Panel Popup
Clipped by WebSphere's column layouts. See screenshot.

Panel Positioned
Rendering out a comment containing a dynamic value. This looks to be non-portal specific as per http://jira.icesoft.org/browse/ICE-8000. See screenshot.

Attaching screenshots referred to in previous comment.

WebSphere Portal 6.1 and 7 are pretty much the same when tested so, other than the couple of minor issues noted, the testing is complete and resolving the case.