ICEsoft.org Forums: ICEfaces, ICEmobile, ICEpdf

http://www.liferay.com/community/forums/-/message_boards/message/4707929

Sorry this should not be a doublepost, but the problem is bounded both to liferay and icefaces and so I think this posting is interesting for all users.

It would be easier if ICEFaces and Liferay would have one forum that concentrates on the issue of developing with ICEFaces portlets for Liferay.
Such an project would help all: Liferay, ICEFaces and all developers.

Best regards,

Gaston

You might want to look at this older forum thread as the configuration for private-session-attributes is tricky.

http://www.icefaces.org/JForum/posts/list/10184.page#43029

Dear Deryk,

thank you very much for your post.

The solution with the Delegateservlet seems not to solve my problem, because the DelegeteServlet is for sharing data between the portal and the portlets and not between the portlets.

As mentioned in the Liferay-Forum sharing data between portlets in different wars works just only this way:
http://www.liferay.com/web/guest/community/wiki/-/wiki/Main/Frequently%20Asked%20Questions#section-Frequently+Asked+Questions-HowDoWeUseTheSessionToShareAttributesBetweenPortletsDeployedAsIndividualWARs.
As I allready wrote in the Liferay forum the user session expired occurs if setting Code:

private-session-attributes>false</private-session-attributes>

.
But if you have another portlet on the same page that belongs to this same war with this attribute set to true, this error does not occur and I can read in the portlet from the other war the value- so it works in this way. If I could make the second portlet invisible of the first war this would be a haclking solution.

I tried the solution that changes the portlet.jar to portlet-api-2.0.jar and set in portal-ext.properties
Code:

 session.shared.attributes=LIFERAY_SHARED_

and with this code I tried to share variables between portlets in different wars with Neill Griffins class:
Code:

 public class PortletSessionUtil {
 
 	
 	public static final String SELECTED_VALUE = "LIFERAY_SHARED_test123";
 	
 	
 	public static Object getSharedSessionAttribute(String key) {
 		FacesContext facesContext = FacesContext.getCurrentInstance();
 		if(facesContext==null)
 			return null;
 		
 		PortletSession portletSession =
 			(PortletSession)facesContext.getExternalContext().getSession(false);
 		return portletSession.getAttribute(
 			key, PortletSession.APPLICATION_SCOPE);
 	}
 
 	public static void setSharedSessionAttribute(String key, Object value) {
 		FacesContext facesContext = FacesContext.getCurrentInstance();
 		if(facesContext==null)
 			return;
 		
 		PortletSession portletSession =
 			(PortletSession)facesContext.getExternalContext().getSession(false);
 		portletSession.setAttribute(
 			key, value, PortletSession.APPLICATION_SCOPE);
 	}

but with no effort too.

No I want to try it with the JSR286 events. And the next problem arise, because I have no access to the ActionRequest and ActionResponse.

Like it is described here:
http://www.icefaces.org/docs/v1_8_2/htmlguide/devguide/AdvancedTopics10.html
and here http://www.icefaces.org/JForum/posts/list/8445.page my chance to reach my aim are not very good again :-(.
I want to set the event in this way:
Code:

 
 		    ActionResponse aResponse = (ActionResponse)response;  
 		    QName qname = new QName("http://hdbwcon/portal/portlets/ns" , "hope");  
 			aResponse.setEvent(qname, "next try");
 }

and with no access to this ActionResponse object I will have no luck.

I am using the Liferay portal 5.2.3 and ICEFaces 1.8.2 and I want to ask what would be a solution to share data between 2 portlets in different wars or what would be the best strategy?

Best regards,

Gaston

Yes, the IPC of the Portlet 2.0 is not yet supported in ICEfaces 1.8. That will eventually come with ICEfaces 2.0 and an official implementation of a Portlet Bridge.

As for access to the ActionRequest, that is simply a limitation of using Ajax with the Portlet 1.0 API. Ajax requests go straight to the ICEfaces servlets and not through the portal container so there is no concept of a portlet's ActionRequest in that case.

If the DelegateServlet solution is not a fit for your environment, then I can only suggest some other external sharing solution (e.g. database, shared file-system storage, cache, etc) that the portlets in different .war files could access.

Hi Deryk,

thank you for for your help but I have found another very simple solution ;-).
I am very happy because I invested much time and hope that somebody who will run in the same problem, should not loose so much time than me.

The solution is very simple.

1. Create a Singleton-Class:

Code:

 package sharingdata;
 
 public class Sharingdata {
 
 	
 	private static Sharingdata instance;
 	private String sharedValue;
 	
 	public static Sharingdata getInstance(){
 		if(instance==null)
 			instance=new Sharingdata();
 		return instance;
 	}
 	
 	private Sharingdata(){
 		
 	}
 
 	public String getSharedValue() {
 		return sharedValue;
 	}
 
 	public void setSharedValue(String sharedValue) {
 		this.sharedValue = sharedValue;
 	}
 }

Create a jar of it. Put this jar in the directory liferay/tomcat/lib/ext in my case it is:
liferay-portal-5.2.3/tomcat-6.0.18/lib/ext

All portlets use the same classloader and so in this way the data can be shared.

Because the data are globally they can be seen by everybody. So you have to store for example the unique-email-address of the user and the value, to show the values only to the desired users.
Additionally there should be a mechanism that after logout of the user deletes its data from the SharedClass. But with this simple mechanism you can share data between portlets of different wars.

I guess that's another way to share data. I'm glad you found a way that works for you

Hi,

I guess too ;-), but I did not found it yet that is the problem.
My searching has not reached the end and I will share my knowledge if I find a better solution.

Best regards,

Gaston

I already had this solution in mind, but the problem is, that usually the shared data is session specific. So it must be cleaned when the session runs out. Otherwise there is a big memory leak. This is an additional burden.

I tried to use the PortalDelegateServlet, but like everything in this anti pattern portal server it is bad or undocumented.

<servlet>
<servlet-name>Blocking Servlet</servlet-name>
<servlet-class>
com.liferay.portal.kernel.servlet.PortalDelegateServlet
</servlet-class>
<init-param>
<param-name>servlet-class</param-name>
<param-value>
com.icesoft.faces.webapp.xmlhttp.BlockingServlet
</param-value>
</init-param>
<init-param>
<param-name>sub-context</param-name>
<param-value>/block/*</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>

I don't know what sub-context means. As last hope I have debugged Liferay, but also the source code of Liferay is of course completly undocumented, so this was not giving any hints.

To avoid the memory leak there is a possibility to listen for logout:

http://www.liferay.com/community/forums/-/message_boards/message/3710965

But more safe, if the user closes the browser without explicitly loging out for example, you can do it very easy:
Just save with the value that has to be shared among the portlets the time, this value was setted. Then you need just an Thread that checks regularly if in the datastructure there are values which are older than 30minutes, 1 hour, 2 hour or which periode you think should be used. And if this thread founds an value that is older, it will be deleted from this datastructure.
So you can avoid the memory leak.

Best regards.

I'm not sure if own threads are a good solution. At least in EJB threads are not allowed. I guess it is better to let the servlet container to manage the threads.
Actually the solution with the shared data might be good enough, I only need this last answer how the servlets of ICEfaces are synced.

BR

Perhaps this link helps you with the subcontext:

http://longgoldenears.blogspot.com/2008/03/portaldelegateservlet-servlet-session.html

I don't like my solution too...but as long as I don't have a better one, I am forced to take it ;-) or better :-(

This was the page I got the example from. But the page does not explain how to use the servlet. This is the problem.

I invested today many hours for searching a solution for the problem, but with no result.
There are some solutions but they don't work for Liferay&IceFaces:

1) LIFERAY_SHARED or another prefix:
All variables that have got a certain prefix, you can define in
portal-ext.properties
Code:

 session.shared.attributes=LIFERAY_SHARED_

and put in in the APPLICATION_SCOPE of the session should be visible for all portlets of different wars.
Works not for me.

2) In one posting on ICEFaces I found that just to use portlet-2.0-api in the lib directory of the application, would solution 1) bring to work. I took the portlet.jar from the liferay distribution - I looked in the manifest this is JSR286 - and with no effort.

3) The solution with the DelegateServlet as I understood is just for the direction Portal -> Portlet and not Portlet->Portal.

4) The event mechanism according to JSR286 will not work to, because you don't have access to the ActionRequest with ICEFaces 1.8.x. As Deryk mentioned perhaps this will be able in the ICEFaces 2.0 version, which has at the moment alpha-status.

5) I found one entry that suggests that the ICEFaces-portlet should use an intermediate portlet according to JSR286 which communicates with another JSR286compliant portlet from another war, and over this tunnel realizes IPC between portlets of different wars. I did not try this possilbility out yet- has somebody else?

6) The Liferay-mechanism to declare the variables of your portlet private to false in liferay-portlet.xml ends with an Session Expired Message every 3 seconds. But if you put another useless portlet on the same page it works as it should without this error.

7) If you have the portlets of different wars on the same page you can use JavaScript. Here the link:
http://liferay1.googlecode.com/svn/trunk/snippet/portal-devt/17-inter-portlet-commn-part1.txt

8) There is one mechanism like PortalClassInvoker http://www.liferay.com/web/neil.griffin/blog/-/blogs/sharing-data-between-portlets

Conclusion:
As in many forums mentioned a solution is to use a database, a file or another construction like mine. But I hope there will be one simple well documented example to achieve this in an "normal" way.

;-)

Best regards,

Gaston

Thanks for the examination.

2). We are using Liveray 5.2 with portlet-api 2.0. I always shows the session expired screen.

3) This would be OK, because this removes the session expired screen. I only want to use it to get IceFaces working again. The expired screen blocks all traffic.

4) Yes, true. Also found this.

5) Did not get it. How is the tunnel build? This is the same problem, isn't it? Talking to a different, this time intermediate, portlet?

6) If you put another useless portlet on the same page it works? Really? What happens? I have several portlets on one page, but all are not working. What means useless?

7) Yes, but this is quite ugly because you must have informations about the other portlets. This would break the independence.

8) It seems that this can only be used if the data is not session specific?

2.
Always? For me only if I set private-session variables in liferay-portlet.xml to false.
I use Liferay 5.22 and ICEFaces 1.8.2 and in some case 1.8.1 with tomcat-6.0

5.

I am at the moment not sure myself about the architecture but I suppose it int this way:
2 wars each with one ICEFaces portlet and with an NON-ICEFaces JSR286 compliant portlet.
Each ICEFaces portlet can share data with its NON-ICEFaces portlet.
The both NON-ICEFaces portlet can communicate with each other with the events as introduced with JSR286.
But I don't have a working example and still not sure if this construction would work.

6.
I desribed it here:
http://www.liferay.com/community/forums/-/message_boards/message/4707929

I want IPC between portlets of different wars. So portlet from WAR uses the private-session to false setting to share with the portlet from another WAR - user session expired.
If I put a second portlet on the page where the portlet from the first WAR - the user session expired message - does not appear and everything works as it should. So this portlet is not really needed, but prevents the error message and so I call it useless.

8.
It seems as it something like my solution, just a static class that is visble globally.