Combination View Flat View Tree View
Threads [ Previous | Next ]
toggle
frode aarstad
Icefaces / Liferay / Bridge issue
August 22, 2012 6:06 AM
Answer

frode aarstad

Rank: New Member

Posts: 3

Join Date: August 13, 2012

Recent Posts

We are currently developing a portal based on Liferay 6.1.0 and would like to port some of our old Icefaces applications to run as protlets in the portal. One of the Icefaces applications is rendering a svg image on the server and pushing it to the clients via backing bean and <ice:graphicsImage> during the porting we have run into the same problem as described in the JIRA case below:

http://jira.icesoft.org/browse/ICE-8370

Basically the

<ice:graphicImage mimeType="image/png" value="#{Bean.imageBytes}" height="#{Bean.height}" width="#{Bean.width}" />

Recieves a invalid reference to the dynamic data from the backing bean. The URL that is generated is of the form :

http://localhost:8081/MY-portlet/icefaces/resource/LTIwNjkyOTA3ODY=/

Is this a fundamental problem or can it be solved with proper configuring of our portlets ?

Frode Aarstad
Visual Development
Neil Griffin
RE: Icefaces / Liferay / Bridge issue
August 22, 2012 9:02 AM
Answer

Neil Griffin

LIFERAY STAFF

Rank: Liferay Legend

Posts: 2369

Join Date: July 26, 2005

Recent Posts

Do you see any stacktrace errors in the server log? If so, please post them here.
frode aarstad
RE: Icefaces / Liferay / Bridge issue
August 23, 2012 12:22 AM
Answer

frode aarstad

Rank: New Member

Posts: 3

Join Date: August 13, 2012

Recent Posts

There seem to be no issues on the server side (Tomcat-7.0.23). The server logs the request from the <h:graphicImage> as:

1
2127.0.0.1 - - [23/Aug/2012:07:04:21 +0000] "GET /MY-portlet/icefaces/resource/Mjk3MTM4OTI4/ HTTP/1.1" 404 1087


So the client requests a recource that is not available.

We know that the image is created and made available by the backing bean method called from <h:graphicImage> but there is a mismatch between the URL that the backing bean produces and the URL that the client <h:graphicImage> expects.
Neil Griffin
RE: Icefaces / Liferay / Bridge issue
August 23, 2012 12:38 PM
Answer

Neil Griffin

LIFERAY STAFF

Rank: Liferay Legend

Posts: 2369

Join Date: July 26, 2005

Recent Posts

When you say "old Icefaces applications" are you referring to ICEfaces 1.8? If so, then I would recommend that you perform a small test to see if it will work with ICEfaces 3.1.

The latest version of the Liferay Maven SDK ships with archetypes for Liferay Faces Alloy, ICEfaces, PrimeFaces, and RichFaces. I would recommend that you read Mika Koivisto's blog post titled Getting started with Liferay Maven SDK . After installing the SDK, you can type "mvn archetype:generate" to select an ICEfaces 3.1 portlet archetype for quick project setup.

You can also use Liferay IDE 1.6.0 and the Liferay 6.1.1 Plugins SDK which has a template project for ICEfaces.

WIth ICEfaces 1.8, the Ajax Push mechanism on the server would run the JSF lifecycle in a mock-type of request, and return the rendered results back to the browser.

The reason why I suggest ICEfaces 3.1 is because the Ajax Push mechanism has been redesigned. Since ICEfaces 2.0, the Ajax Push XmlHttpRequest response received by the browser is a simple notification that instructs ICEfaces to issue a new HTTP GET XmlHttpRequest to the server. This request is then received by Liferay Faces Bridge as a portlet ResourceRequest, and runs the JSF lifecycle in a normal manner.

I think it's worth your time to see if it works. If so, then perhaps you could upgrade your portlets to JSF 2.x and ICEfaces 3.1?