ICEfaces
  1. ICEfaces
  2. ICE-7081

Support for WebSphere Portal 7 in ICEfaces 1.8

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.8.3, EE-1.8.2.GA_P04
    • Fix Version/s: EE-1.8.2.GA_P04
    • Component/s: Documentation, QA, Sample Apps
    • Labels:
      None
    • Environment:
      ICEfaces 1 WebSphere portal portlet
    • Affects:
      Documentation (User Guide, Ref. Guide, etc.), Sample App./Tutorial, Compatibility/Configuration
    • Workaround Exists:
      Yes
    • Workaround Description:
      Hide
      The issues related to clipping or slightly offset rendering are typically related to CSS conflicts between the sample styles and the portal styles and can usually be fixed with slight tweaks to either or by overriding them with application specific styles.
      Show
      The issues related to clipping or slightly offset rendering are typically related to CSS conflicts between the sample styles and the portal styles and can usually be fixed with slight tweaks to either or by overriding them with application specific styles.

      Description

      ICEfaces 1.8 needs to be verified to run on WebSphere Portal 7
      1. wps7-panel-popup.png
        378 kB
      2. wps7-panel-positioned.png
        343 kB
      3. wps7-tabset-dynamic.png
        360 kB

        Activity

        Hide
        Deryk Sinotte added a comment -

        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.

        Show
        Deryk Sinotte added a comment - 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.
        Hide
        Deryk Sinotte added a comment -

        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.
        Show
        Deryk Sinotte added a comment - 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.
        Hide
        Deryk Sinotte added a comment -

        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.

        Show
        Deryk Sinotte added a comment - 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.
        Hide
        Deryk Sinotte added a comment -

        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:

        {0}

        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.

        Show
        Deryk Sinotte added a comment - 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: {0} 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.
        Hide
        Deryk Sinotte added a comment -

        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.

        Show
        Deryk Sinotte added a comment - 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.
        Hide
        Deryk Sinotte added a comment - - edited

        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.

        Show
        Deryk Sinotte added a comment - - edited 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.
        Hide
        Deryk Sinotte added a comment -

        Attaching screenshots referred to in previous comment.

        Show
        Deryk Sinotte added a comment - Attaching screenshots referred to in previous comment.
        Hide
        Deryk Sinotte added a 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.

        Show
        Deryk Sinotte added a 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.

          People

          • Assignee:
            Deryk Sinotte
            Reporter:
            Deryk Sinotte
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: