ICEfaces-EE
  1. ICEfaces-EE
  2. IPCK-259

Add ICEfaces EE Support for WebSphere Portal 7

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: EE-3.0.0.GA
    • Component/s: Release
    • Labels:
      None
    • Environment:
      ICEfaces EE 2.0.0, WebSphere Portal 7, PortletFacesBridge
    • Affects:
      Documentation (User Guide, Ref. Guide, etc.), Compatibility/Configuration

      Description

      This JIRA is to certify and document support for using ICEfaces EE 2 with WebSphere Portal 7.

      1. The existing ICEfaces 2 portlet samples should be tested successfully with WebSphere Portal 7.
      2. The instructions for using ICEfaces with WebSphere 7 should be documented and added to the ICEfaces EE Wiki on this page: http://wiki.icesoft.com/display/IFEE2/WebSphere+Portal+7

      See the following existing Portlet docs as a reference:

      - ICEfaces 2 Portlets doc: http://wiki.icefaces.org/display/ICE/Portlet+Development
      - Existing ICEfaces EE 1.8 WebSphere Portal Docs: http://wiki.icesoft.com/display/ICEboxDev/Configuring+WebSphere+6.1.0.1+Portal

        Issue Links

          Activity

          Hide
          Ben Simpson added a comment -

          Using the portlet bridge, we are running into problems that the response is already committed when the bridge is trying to reset it.

          See exception below:

          [1/31/11 19:55:46:264 EST] 0000003a SystemErr R java.lang.IllegalStateException: clearBuffer(): illegal state--> stream is committed
          [1/31/11 19:55:46:265 EST] 0000003a SystemErr R at com.ibm.wsspi.webcontainer.util.BufferedServletOutputStream.clearBuffer(BufferedServletOutputStream.java:599)
          [1/31/11 19:55:46:267 EST] 0000003a SystemErr R at com.ibm.ws.webcontainer.srt.SRTServletResponse.reset(SRTServletResponse.java:1045)
          [1/31/11 19:55:46:267 EST] 0000003a SystemErr R at javax.servlet.ServletResponseWrapper.reset(ServletResponseWrapper.java:193)
          [1/31/11 19:55:46:267 EST] 0000003a SystemErr R at javax.servlet.ServletResponseWrapper.reset(ServletResponseWrapper.java:193)
          [1/31/11 19:55:46:267 EST] 0000003a SystemErr R at javax.servlet.ServletResponseWrapper.reset(ServletResponseWrapper.java:193)
          [1/31/11 19:55:46:267 EST] 0000003a SystemErr R at javax.servlet.ServletResponseWrapper.reset(ServletResponseWrapper.java:193)
          [1/31/11 19:55:46:267 EST] 0000003a SystemErr R at com.ibm.ws.portletcontainer.core.impl.PortletResponseImpl.reset(PortletResponseImpl.java:354)
          [1/31/11 19:55:46:268 EST] 0000003a SystemErr R at org.portletfaces.bridge.context.ExternalContextImpl.responseReset(ExternalContextImpl.java:438)
          [1/31/11 19:55:46:268 EST] 0000003a SystemErr R at com.sun.faces.context.ExceptionHandlerImpl.throwIt(ExceptionHandlerImpl.java:251)
          [1/31/11 19:55:46:268 EST] 0000003a SystemErr R at com.sun.faces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:141)
          [1/31/11 19:55:46:268 EST] 0000003a SystemErr R at org.icefaces.impl.application.ExtendedExceptionHandler.handle(ExtendedExceptionHandler.java:110)
          [1/31/11 19:55:46:269 EST] 0000003a SystemErr R at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119)
          [1/31/11 19:55:46:269 EST] 0000003a SystemErr R at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:113)
          [1/31/11 19:55:46:269 EST] 0000003a SystemErr R at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
          [1/31/11 19:55:46:270 EST] 0000003a SystemErr R at org.portletfaces.bridge.BridgeImpl.doFacesRequest(BridgeImpl.java:238)
          [1/31/11 19:55:46:275 EST] 0000003a SystemErr R at org.portletfaces.bridge.GenericFacesPortlet.doView(GenericFacesPortlet.java:194)
          [1/31/11 19:55:46:275 EST] 0000003a SystemErr R at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:328)
          [1/31/11 19:55:46:277 EST] 0000003a SystemErr R at javax.portlet.GenericPortlet.render(GenericPortlet.java:222)

          Show
          Ben Simpson added a comment - Using the portlet bridge, we are running into problems that the response is already committed when the bridge is trying to reset it. See exception below: [1/31/11 19:55:46:264 EST] 0000003a SystemErr R java.lang.IllegalStateException: clearBuffer(): illegal state--> stream is committed [1/31/11 19:55:46:265 EST] 0000003a SystemErr R at com.ibm.wsspi.webcontainer.util.BufferedServletOutputStream.clearBuffer(BufferedServletOutputStream.java:599) [1/31/11 19:55:46:267 EST] 0000003a SystemErr R at com.ibm.ws.webcontainer.srt.SRTServletResponse.reset(SRTServletResponse.java:1045) [1/31/11 19:55:46:267 EST] 0000003a SystemErr R at javax.servlet.ServletResponseWrapper.reset(ServletResponseWrapper.java:193) [1/31/11 19:55:46:267 EST] 0000003a SystemErr R at javax.servlet.ServletResponseWrapper.reset(ServletResponseWrapper.java:193) [1/31/11 19:55:46:267 EST] 0000003a SystemErr R at javax.servlet.ServletResponseWrapper.reset(ServletResponseWrapper.java:193) [1/31/11 19:55:46:267 EST] 0000003a SystemErr R at javax.servlet.ServletResponseWrapper.reset(ServletResponseWrapper.java:193) [1/31/11 19:55:46:267 EST] 0000003a SystemErr R at com.ibm.ws.portletcontainer.core.impl.PortletResponseImpl.reset(PortletResponseImpl.java:354) [1/31/11 19:55:46:268 EST] 0000003a SystemErr R at org.portletfaces.bridge.context.ExternalContextImpl.responseReset(ExternalContextImpl.java:438) [1/31/11 19:55:46:268 EST] 0000003a SystemErr R at com.sun.faces.context.ExceptionHandlerImpl.throwIt(ExceptionHandlerImpl.java:251) [1/31/11 19:55:46:268 EST] 0000003a SystemErr R at com.sun.faces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:141) [1/31/11 19:55:46:268 EST] 0000003a SystemErr R at org.icefaces.impl.application.ExtendedExceptionHandler.handle(ExtendedExceptionHandler.java:110) [1/31/11 19:55:46:269 EST] 0000003a SystemErr R at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119) [1/31/11 19:55:46:269 EST] 0000003a SystemErr R at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:113) [1/31/11 19:55:46:269 EST] 0000003a SystemErr R at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) [1/31/11 19:55:46:270 EST] 0000003a SystemErr R at org.portletfaces.bridge.BridgeImpl.doFacesRequest(BridgeImpl.java:238) [1/31/11 19:55:46:275 EST] 0000003a SystemErr R at org.portletfaces.bridge.GenericFacesPortlet.doView(GenericFacesPortlet.java:194) [1/31/11 19:55:46:275 EST] 0000003a SystemErr R at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:328) [1/31/11 19:55:46:277 EST] 0000003a SystemErr R at javax.portlet.GenericPortlet.render(GenericPortlet.java:222)
          Hide
          Ben Simpson added a comment - - edited

          Using the portletfaces trunk I was able to get the PortletFaces example portlets to run by doing the following:

          Upgrade WebSphere Portal and AppServer to the latest Fix for v7.

          Update org.portletfaces.bridge.container.websphere.PortletContainerWebSphereImpl.java to do the following:

          • return false when asked if it supports adding script resources to the header.
          • override "application/xhtml+xml" to "text/html" when setting mime response content type

          These changes will result in a portlet that embeds its javascripts into the portlet body which isn't the desired result - they should be embedded into the head leveraging the Portlet 2.0 specification's two phase rendering support. A separate JIRA item will be created to support this (http://jira.icefaces.org/browse/ICE-6540).

          Show
          Ben Simpson added a comment - - edited Using the portletfaces trunk I was able to get the PortletFaces example portlets to run by doing the following: Upgrade WebSphere Portal and AppServer to the latest Fix for v7. Update org.portletfaces.bridge.container.websphere.PortletContainerWebSphereImpl.java to do the following: return false when asked if it supports adding script resources to the header. override "application/xhtml+xml" to "text/html" when setting mime response content type These changes will result in a portlet that embeds its javascripts into the portlet body which isn't the desired result - they should be embedded into the head leveraging the Portlet 2.0 specification's two phase rendering support. A separate JIRA item will be created to support this ( http://jira.icefaces.org/browse/ICE-6540 ).
          Hide
          Ben Simpson added a comment -

          This file is a part of the portletFaces project.

          Show
          Ben Simpson added a comment - This file is a part of the portletFaces project.
          Hide
          Deryk Sinotte added a comment -

          Adding development notes I had taken while working on this...

          As WebSphere 7 is a streaming portal (as compared to a buffering portal like Liferay), it's behaviour is significantly different when it comes to putting resources into the <head>. The first thing is that it must be configured properly to have this behaviour. To do that, you must add the following to the portlet.xml file:

          ...
          <container-runtime-option>
          <name>javax.portlet.renderHeaders</name>
          <value>true</value>
          </container-runtime-option>
          </portlet>

          This tells WebSphere to use a 2-phase pass where the initial request from the client is split into two separate requests to the bridge - 1st pass to get the <head> resources and the 2nd pass to get the portlet markup. With JSF, the <head> resources are generally added using UIViewRoot.addComponentResource() but this can be called in various places in the code and at various times in the lifecycle. In a streaming server, the <head> resources must be gathered and supplied to the output stream before any markup is written.

          The current strategy is to extend that PortletFaces Bridge with our own library. Right now that library is called icefaces-ee-portletfaces and there is a natural extension point to provide our own BridgeFactory. So in the faces-config.xml we set:

          <factory>
          <factory-extension>
          <bridge:bridge-factory>com.icesoft.portletfaces.bridge.BridgeFactoryImpl</bridge:bridge-factory>
          </factory-extension>
          </factory>

          This factory allows us to override the Bridge implemenation provided by PortletFaces and implement the doFacesHeaders() method. This is the method that is called in the 1st request pass done by WebSphere to gather the <head> resources.

          Show
          Deryk Sinotte added a comment - Adding development notes I had taken while working on this... As WebSphere 7 is a streaming portal (as compared to a buffering portal like Liferay), it's behaviour is significantly different when it comes to putting resources into the <head>. The first thing is that it must be configured properly to have this behaviour. To do that, you must add the following to the portlet.xml file: ... <container-runtime-option> <name>javax.portlet.renderHeaders</name> <value>true</value> </container-runtime-option> </portlet> This tells WebSphere to use a 2-phase pass where the initial request from the client is split into two separate requests to the bridge - 1st pass to get the <head> resources and the 2nd pass to get the portlet markup. With JSF, the <head> resources are generally added using UIViewRoot.addComponentResource() but this can be called in various places in the code and at various times in the lifecycle. In a streaming server, the <head> resources must be gathered and supplied to the output stream before any markup is written. The current strategy is to extend that PortletFaces Bridge with our own library. Right now that library is called icefaces-ee-portletfaces and there is a natural extension point to provide our own BridgeFactory. So in the faces-config.xml we set: <factory> <factory-extension> <bridge:bridge-factory>com.icesoft.portletfaces.bridge.BridgeFactoryImpl</bridge:bridge-factory> </factory-extension> </factory> This factory allows us to override the Bridge implemenation provided by PortletFaces and implement the doFacesHeaders() method. This is the method that is called in the 1st request pass done by WebSphere to gather the <head> resources.
          Hide
          Deryk Sinotte added a comment -

          Work in ICE-6851 have improved the behaviour of Push on WebSphere Portal 7. I have had some success running the chat portlet on two browsers. However, I do see a lot of threading related exceptions thrown in the logs related to:

          Caused by: java.lang.IllegalStateException: prepareThread not called for Thread Thread[WebContainer : 3,5,main]
          at com.ibm.wps.state.information.ThreadSafePlutoInformationProviderProxy.getProvider(ThreadSafePlutoInformationProviderProxy.java:201)
          at com.ibm.wps.state.information.ThreadSafePlutoInformationProviderProxy.setResponseContentType(ThreadSafePlutoInformationProviderProxy.java:414)
          at com.ibm.wps.pe.pc.waspc.services.information.WaspcContentTypeProviderImpl.setResponseContentType(WaspcContentTypeProviderImpl.java:310)
          at com.ibm.ws.portletcontainer.core.impl.ResourceResponseImpl.setContentType(ResourceResponseImpl.java:37)
          at org.portletfaces.bridge.container.PortletContainerImpl.setMimeResponseContentType(PortletContainerImpl.java:417)
          at org.portletfaces.bridge.context.ExternalContextImpl.setResponseContentType(ExternalContextImpl.java:1132)
          at org.icefaces.impl.push.servlet.ProxyHttpServletResponse.setContentType(ProxyHttpServletResponse.java:69)
          at org.icepush.servlet.ServletRequestResponse.setHeader(ServletRequestResponse.java:218)
          at org.icepush.http.standard.FixedSizeContentHandler.respond(FixedSizeContentHandler.java:49)
          at org.icepush.http.standard.FixedXMLContentHandler.respond(FixedXMLContentHandler.java:37)
          at org.icepush.servlet.ServletRequestResponse.respondWith(ServletRequestResponse.java:206)
          at org.icepush.servlet.ThreadBlockingAdaptingServlet$ThreadBlockingRequestResponse.respondWith(ThreadBlockingAdaptingServlet.java:67)
          at org.icepush.BlockingConnectionServer.respondIfPendingRequest(BlockingConnectionServer.java:136)
          ... 144 more

          Show
          Deryk Sinotte added a comment - Work in ICE-6851 have improved the behaviour of Push on WebSphere Portal 7. I have had some success running the chat portlet on two browsers. However, I do see a lot of threading related exceptions thrown in the logs related to: Caused by: java.lang.IllegalStateException: prepareThread not called for Thread Thread [WebContainer : 3,5,main] at com.ibm.wps.state.information.ThreadSafePlutoInformationProviderProxy.getProvider(ThreadSafePlutoInformationProviderProxy.java:201) at com.ibm.wps.state.information.ThreadSafePlutoInformationProviderProxy.setResponseContentType(ThreadSafePlutoInformationProviderProxy.java:414) at com.ibm.wps.pe.pc.waspc.services.information.WaspcContentTypeProviderImpl.setResponseContentType(WaspcContentTypeProviderImpl.java:310) at com.ibm.ws.portletcontainer.core.impl.ResourceResponseImpl.setContentType(ResourceResponseImpl.java:37) at org.portletfaces.bridge.container.PortletContainerImpl.setMimeResponseContentType(PortletContainerImpl.java:417) at org.portletfaces.bridge.context.ExternalContextImpl.setResponseContentType(ExternalContextImpl.java:1132) at org.icefaces.impl.push.servlet.ProxyHttpServletResponse.setContentType(ProxyHttpServletResponse.java:69) at org.icepush.servlet.ServletRequestResponse.setHeader(ServletRequestResponse.java:218) at org.icepush.http.standard.FixedSizeContentHandler.respond(FixedSizeContentHandler.java:49) at org.icepush.http.standard.FixedXMLContentHandler.respond(FixedXMLContentHandler.java:37) at org.icepush.servlet.ServletRequestResponse.respondWith(ServletRequestResponse.java:206) at org.icepush.servlet.ThreadBlockingAdaptingServlet$ThreadBlockingRequestResponse.respondWith(ThreadBlockingAdaptingServlet.java:67) at org.icepush.BlockingConnectionServer.respondIfPendingRequest(BlockingConnectionServer.java:136) ... 144 more
          Hide
          Deryk Sinotte added a comment -

          The closest issue I could find that seemed remotely related to this is here:

          https://www-304.ibm.com/support/docview.wss?uid=swg1PM14290

          The issue says it's a logging/tracing issue only however, the stack trace is different and the problem is reported against WebSphere Portal 6.1 rather than WebSphere Portal 7.

          Show
          Deryk Sinotte added a comment - The closest issue I could find that seemed remotely related to this is here: https://www-304.ibm.com/support/docview.wss?uid=swg1PM14290 The issue says it's a logging/tracing issue only however, the stack trace is different and the problem is reported against WebSphere Portal 6.1 rather than WebSphere Portal 7.
          Hide
          Deryk Sinotte added a comment -

          Updating the current state of the Compat and ACE Showcase examples:

          General Issues:

          • Push still not working reliably which seems to be related to some kind of Threading issues as noted previously
          • Many logging warnings similar to the following:
            [5/31/11 16:38:18:653 PDT] 0000004d srt W com.ibm.ws.webcontainer.srt.SRTServletResponse setStatus WARNING: Cannot set status. Response already committed.
            [6/1/11 10:06:24:526 PDT] 0000002c flash W JSF1095: The response was already committed by the time we tried to set the outgoing cookie for the flash. Any values stored to the flash will not be available on the next request.
          • Downloading and processing GMap and CKEditor resources for every portlet is generally not a good experience when loading a portal page.

          Compat Showcase Issues:

          • Can't get the ckeditor.js resource to resolve:

          http://192.168.55.111:10039/wps/component-showcase/icefaces/resource/LTE5NDk5MzQyNTU=//ckeditor.js

          • Problems with city file. I thought this might be the reason for AutoComplete not functioning but this may just a harmless deployment warning.

          [5/31/11 16:36:39:515 PDT] 0000003a wtp W org.eclipse.jst.j2ee.commonarchivecore.internal.strategy.LoadStrategyImpl createFile FileNotFoundException creating [ C:\IBM\WebSphere\wp_profile\installedApps\icesoftpc\ICECompShow.ear\component-showcas.war\WEB-INF\classes\org\icefaces\application\showcase\view\resources\city.xml.zip/null ]

          • AutoComplete doesn't work. The update comes back with the cities as part of a huge update of the whole form:
            <eval><Unable to render embedded object: File (iceform:AutoCmpTxt');]]></eval><eval><) not found.[CDATA[Ice.Scriptaculous.Autocompleter.Finder.find('A4274:iceform:AutoCmpTxt').updateNOW('<div><div>Yabucoa</div><div>Yachats</div><div>Yacolt</div><div>Yadkinville</div><div>Yakima</div><div>Yalaha</div><div>Yale</div><div>Yamhill</div><div>Yampa</div><div>Yancey</div><div>Yanceyville</div><div>Yankeetown</div><div>Yankton</div><div>Yantic</div><div>Yantis</div></div>');//-2131117978]]></eval>

          but perhaps can't find the elements to apply it to:

          [window.compat] Building Ice Autocompleter ID [A4274:iceform:AutoCmpTxt]
          [window.compat] Element not found id[A4274:iceform:AutoCmpTxt] element[[object HTMLInputElement]] type [INPUT]

          • Google Maps renders but reports this in Firebug when interacting with it:
            [window] Error [status: malformedXML code: 200]: a is null
            exception ? console.er...ror(formatOutput(category, message));
          • Buttons and Links reset button is not resetting the value
          • Popups have some layout/display/z-order issues that make them a bit unusable. It looks like the the popups and the modal overlay are hidden behind the second column. This doesn't appear to be the problem with AutoComplete, though.

          ACE Showcase Issues:

          • Barely functional at all. Clicking on some things appears to generate some behaviour but there are JS errors (one for each portlet):

          d is null
          d is null
          d is null
          ice.component.tabset is undefined
          [Break On This Error] </p></div></div><div id="A7721:tab...43316427301379" autocomplete="off" />
          04_Sjz...gBuwWkr (line 304)
          ice.component.tabset is undefined
          [Break On This Error] </form></span></div></div><div id="A76...kUIOnSubmit: false});</script></span>
          04_Sjz...gBuwWkr (line 372)
          ice.component.tabset is undefined
          [Break On This Error] </form></div></div><div id="A7752:myTa...kUIOnSubmit: false});</script></span>

          and many missing resources. Firebug shows a number of requests that return a status of 200 but no content. Unfortunately, because of the "encoded" URLs it's difficult to diagnose exactly what's missing. For example:
          http://192.168.55.111:10039/wps/myportal/!ut/p/b1/hY1dC4IwFIZ_iz8gzjbdtMth0UaWEwnbbmLIMMEPsLK_36pr61y88MLzPgcMaEwYIZEPOIMZ7Nw29t6Og-3e3bALYipUWUqjfa62SGJJlSg4Rgx7QHsg3XERxRlCCU0wklycYlZuCOLhv30F5oP8MnwdC8cRHMXYO2_SJl58daBQTe42PqbaQVHb-uoyN7tO2cZBCTqH3nRruUqeBQ-CFzGpnSk!/

          Show
          Deryk Sinotte added a comment - Updating the current state of the Compat and ACE Showcase examples: General Issues: Push still not working reliably which seems to be related to some kind of Threading issues as noted previously Many logging warnings similar to the following: [5/31/11 16:38:18:653 PDT] 0000004d srt W com.ibm.ws.webcontainer.srt.SRTServletResponse setStatus WARNING: Cannot set status. Response already committed. [6/1/11 10:06:24:526 PDT] 0000002c flash W JSF1095: The response was already committed by the time we tried to set the outgoing cookie for the flash. Any values stored to the flash will not be available on the next request. Downloading and processing GMap and CKEditor resources for every portlet is generally not a good experience when loading a portal page. Compat Showcase Issues: Can't get the ckeditor.js resource to resolve: http://192.168.55.111:10039/wps/component-showcase/icefaces/resource/LTE5NDk5MzQyNTU=//ckeditor.js Problems with city file. I thought this might be the reason for AutoComplete not functioning but this may just a harmless deployment warning. [5/31/11 16:36:39:515 PDT] 0000003a wtp W org.eclipse.jst.j2ee.commonarchivecore.internal.strategy.LoadStrategyImpl createFile FileNotFoundException creating [ C:\IBM\WebSphere\wp_profile\installedApps\icesoftpc\ICECompShow.ear\component-showcas.war\WEB-INF\classes\org\icefaces\application\showcase\view\resources\city.xml.zip/null ] AutoComplete doesn't work. The update comes back with the cities as part of a huge update of the whole form: <eval>< Unable to render embedded object: File (iceform:AutoCmpTxt');]]></eval><eval><) not found. [CDATA [Ice.Scriptaculous.Autocompleter.Finder.find('A4274:iceform:AutoCmpTxt').updateNOW('<div><div>Yabucoa</div><div>Yachats</div><div>Yacolt</div><div>Yadkinville</div><div>Yakima</div><div>Yalaha</div><div>Yale</div><div>Yamhill</div><div>Yampa</div><div>Yancey</div><div>Yanceyville</div><div>Yankeetown</div><div>Yankton</div><div>Yantic</div><div>Yantis</div></div>');//-2131117978] ]></eval> but perhaps can't find the elements to apply it to: [window.compat] Building Ice Autocompleter ID [A4274:iceform:AutoCmpTxt] [window.compat] Element not found id [A4274:iceform:AutoCmpTxt] element[ [object HTMLInputElement] ] type [INPUT] Google Maps renders but reports this in Firebug when interacting with it: [window] Error [status: malformedXML code: 200] : a is null exception ? console.er...ror(formatOutput(category, message)); Buttons and Links reset button is not resetting the value Popups have some layout/display/z-order issues that make them a bit unusable. It looks like the the popups and the modal overlay are hidden behind the second column. This doesn't appear to be the problem with AutoComplete, though. ACE Showcase Issues: Barely functional at all. Clicking on some things appears to generate some behaviour but there are JS errors (one for each portlet): d is null d is null d is null ice.component.tabset is undefined [Break On This Error] </p></div></div><div id="A7721:tab...43316427301379" autocomplete="off" /> 04_Sjz...gBuwWkr (line 304) ice.component.tabset is undefined [Break On This Error] </form></span></div></div><div id="A76...kUIOnSubmit: false});</script></span> 04_Sjz...gBuwWkr (line 372) ice.component.tabset is undefined [Break On This Error] </form></div></div><div id="A7752:myTa...kUIOnSubmit: false});</script></span> and many missing resources. Firebug shows a number of requests that return a status of 200 but no content. Unfortunately, because of the "encoded" URLs it's difficult to diagnose exactly what's missing. For example: http://192.168.55.111:10039/wps/myportal/!ut/p/b1/hY1dC4IwFIZ_iz8gzjbdtMth0UaWEwnbbmLIMMEPsLK_36pr61y88MLzPgcMaEwYIZEPOIMZ7Nw29t6Og-3e3bALYipUWUqjfa62SGJJlSg4Rgx7QHsg3XERxRlCCU0wklycYlZuCOLhv30F5oP8MnwdC8cRHMXYO2_SJl58daBQTe42PqbaQVHb-uoyN7tO2cZBCTqH3nRruUqeBQ-CFzGpnSk!/
          Hide
          Deryk Sinotte added a comment -

          Just a bit more info on the ACE issues. We have some custom code in there for replacing stuff in the URLs. For example we use this regular expression to locate yui related info:

          libraryPatternPortlets: /^(.[\_\-\.\&\?])ln\=yui%2F[0-9a-zA-Z_\.]+(.)$/,

          However, because WebSphere munges the URLs to be pratically unrecognizable, this technique doesn't work and we get some of the JS errors we're seeing when this is later executed because no matches are found:

          library = whole[3].match(ice.yui3.libraryPatternPortlets);

          Show
          Deryk Sinotte added a comment - Just a bit more info on the ACE issues. We have some custom code in there for replacing stuff in the URLs. For example we use this regular expression to locate yui related info: libraryPatternPortlets: /^(. [\_\-\.\&\?] )ln\=yui%2F [0-9a-zA-Z_\.] +(. )$/, However, because WebSphere munges the URLs to be pratically unrecognizable, this technique doesn't work and we get some of the JS errors we're seeing when this is later executed because no matches are found: library = whole [3] .match(ice.yui3.libraryPatternPortlets);
          Hide
          Deryk Sinotte added a comment -

          Assigning to Greg who is currently working on support for this feature.

          Show
          Deryk Sinotte added a comment - Assigning to Greg who is currently working on support for this feature.
          Hide
          Greg Dick added a comment -

          http://jira.icefaces.org/browse/ICE-7807 ELExpression stack overflow on logout
          http://jira.icefaces.org/browse/PUSH-162 Various uncaught exceptions thrown in Push environment
          http://jira.icefaces.org/browse/ICE-7790 Cookie problem with myfaces (fixed)
          http://jira.icefaces.org/browse/ICE-7791 IllegalStateExceptions changing character encoding

          More as they are discovered

          Show
          Greg Dick added a comment - http://jira.icefaces.org/browse/ICE-7807 ELExpression stack overflow on logout http://jira.icefaces.org/browse/PUSH-162 Various uncaught exceptions thrown in Push environment http://jira.icefaces.org/browse/ICE-7790 Cookie problem with myfaces (fixed) http://jira.icefaces.org/browse/ICE-7791 IllegalStateExceptions changing character encoding More as they are discovered
          Hide
          Greg Dick added a comment -

          A couple new issues:

          http://jira.icesoft.org/browse/ICE-7875 (Setting the response code in the wrong place PortletFacesBridge)
          http://jira.icefaces.org/browse/ICE-7874 (Exception returned by server in Data Exporter)

          Show
          Greg Dick added a comment - A couple new issues: http://jira.icesoft.org/browse/ICE-7875 (Setting the response code in the wrong place PortletFacesBridge) http://jira.icefaces.org/browse/ICE-7874 (Exception returned by server in Data Exporter)
          Hide
          Greg Dick added a comment -

          Additional links

          Show
          Greg Dick added a comment - Additional links
          Hide
          Greg Dick added a comment -

          The problems encountered in WSP 7 environment consisted of managing a couple of bugs in MyFaces, a bug in the PortletFaces Bridge code, a problem with our push product using Threads that couldn't inherit MyFaces Portlet context ThreadLocal Variables, and various problems with some of ICEFaces resource code that wasn't encoding URLs properly for IBM's URL munging environment.

          Several issues clouded debugging this issue. There were a few spots in the push code where exceptions were silently caught and rethrown. One of these places was in a TimerTask, which is a no-no as it stops the Task from being rescheduled. This stopped the blocking connection from returning a <noop/> response if there were no responses pending.

          Another issue was trying to determine the place within the code that was throwing the exception since WebSphere doesn't fill in stack traces from inside its own code. We managed to get Idea to stop at a breakpoint when an IllegalStateException was thrown and to get a stack trace via the debugger. This is how we managed to find the spot in the IBM code where it was throwing the exception.

          Early on it looked like the push code with the various push and viewIds was a problem, but those symptoms turned out to be related to missing functionality caused by the exceptions from using threads. It looks like that group notification code is pretty sound at this stage. Part of that difficulty was understanding which request was what, given WebSphere's URL mangling process. It wasn't clear that all the requests passed through the Portlet ResourceHandlerImpl, but they do, and it's easy to put the cleartext URL into a header so that it can be read while looking through the network traffic log. Then we were able to identify the problems with the missing resources.

          Show
          Greg Dick added a comment - The problems encountered in WSP 7 environment consisted of managing a couple of bugs in MyFaces, a bug in the PortletFaces Bridge code, a problem with our push product using Threads that couldn't inherit MyFaces Portlet context ThreadLocal Variables, and various problems with some of ICEFaces resource code that wasn't encoding URLs properly for IBM's URL munging environment. Several issues clouded debugging this issue. There were a few spots in the push code where exceptions were silently caught and rethrown. One of these places was in a TimerTask, which is a no-no as it stops the Task from being rescheduled. This stopped the blocking connection from returning a <noop/> response if there were no responses pending. Another issue was trying to determine the place within the code that was throwing the exception since WebSphere doesn't fill in stack traces from inside its own code. We managed to get Idea to stop at a breakpoint when an IllegalStateException was thrown and to get a stack trace via the debugger. This is how we managed to find the spot in the IBM code where it was throwing the exception. Early on it looked like the push code with the various push and viewIds was a problem, but those symptoms turned out to be related to missing functionality caused by the exceptions from using threads. It looks like that group notification code is pretty sound at this stage. Part of that difficulty was understanding which request was what, given WebSphere's URL mangling process. It wasn't clear that all the requests passed through the Portlet ResourceHandlerImpl, but they do, and it's easy to put the cleartext URL into a header so that it can be read while looking through the network traffic log. Then we were able to identify the problems with the missing resources.

            People

            • Assignee:
              Greg Dick
              Reporter:
              Ken Fyten
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: