Details
-
Type:
New Feature
-
Status: Closed
-
Priority:
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
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
- depends on
-
ICE-7790
Bridge enters browser id acquisition loop in not picking up browser id from responses in WebSphere Portal environment
-
- Closed
-
-
ICE-7791
Push application (Myfaces, WebSphere, Portal) throws IllegalStateException changing the characterEncoding
-
- Closed
-
-
ICE-7807
Logout button in portlet chat application and WebSphere throws exception
-
- Closed
-
-
PUSH-162
Various Runtime Exceptions in WebSphere Portal push environment
-
- Closed
-
- is duplicated by
-
IPCK-309
Add ICEfaces EE 3 Support for WebSphere Portal 7
-
- Closed
-
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
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).
This file is a part of the portletFaces project.
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.
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
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.
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!/
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);
Assigning to Greg who is currently working on support for this feature.
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
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)
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.
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)