Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 3.0
-
Fix Version/s: 3.0.1, EE-3.0.0.GA
-
Component/s: Bridge
-
Labels:None
-
Environment:ICEFaces 3 + myfaces 2.1.6 + WebSphere 7 + Portlet
Description
On converting to Myfaces 2.1.6, the listen for push request wouldn't have the browserId cookie set, leading to the ConfigurationServer responding with a browserId, not as a cookie, but in the body of the response. The bridge wasn't picking up this value, leading to a tight loop where the next listen for push would trigger the cycle again.
Issue Links
- blocks
-
IPCK-259
Add ICEfaces EE Support for WebSphere Portal 7
-
- Closed
-
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
The fix uses 'Cookie' function (found in our bridge-support project) to make sure the cookie has its 'path' attribute defined. Most probably the headers sent by Websphere+Myfaces2.1.6 force the browsers to be more strict on how cookies can be created.
Show
Mircea Toma
added a comment - The fix uses 'Cookie' function (found in our bridge-support project) to make sure the cookie has its 'path' attribute defined. Most probably the headers sent by Websphere+Myfaces2.1.6 force the browsers to be more strict on how cookies can be created.
Mircea has provided a patch containing a solution for this issue. I don't have an idea why 2.1.6 broke the application (vs 2.1.3) nor why the patch works.