This week's book giveaway is in the Clojure forum.
We're giving away four copies of Clojure in Action and have Amit Rathore and Francis Avila on-line!
See this thread for details.
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Remote Portlets + WSRP + JSR 168

 
Rohit Mehra
Greenhorn
Posts: 1
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I have just started working on portlets & remote portlets.

I want to implement
1) Create Producer portlet running on Jboss portal server 1
2) Create Consumer portlet running on Jboss portal server 2
3) Session managment between both of them.

Can anybody help me to implement the above scenario using JSR 168 specifications?
 
David O'Meara
Rancher
Posts: 13459
Android Eclipse IDE Ubuntu
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
assuming you're clustering the JBoss instances and JBoss server supports WSRP (I haven't checked) it depends what your require in Session Management.
eg I just finished doing some fairly extensive WSRP testing using Liferay and the support is very good, but while the Portlet spec defines management of state between portlets and portlet instances it does not define any inter-portlet state management. ie the how portlets would maintain and share session state. Portlets are supposed to communicate via IPC (JSR 286 not 168) and this is covered by WSRP, but again the concept of session-based state is not.

Stepping back to Liferay for a second, there are a few ways to share session state using Liferay-specific mechanisms and it is also possible to access the HTTP Session directly to manipulate state. Regardless of how you maintain state and of whether you share state between portlets, the portal server tends to provide support for portlet state by delegating to the HTTP session and adding a prefix to the binding name to maintain a unique namespace and prevent collision. Because of this, portlet session clustering can be left to the general HTTP session clustering provided by the application server.

With a few provisos:
In Liferay (maybe others) a WSRP Consumer needs server affinity with a WSRP Producer for each conversation (is sticky connections). If you have multiple portlets, they need to be announced on the producer in a single WSRP Producer and they need to made available on the consumer using a single WSRP Consumer. If you do anything else, or have a mixture of remote and local portlets, you may find that session sharing fails.

That's more or less a direct brain dump of the WSRP session state testing we did with Liferay 6EE SP1
 
I agree. Here's the link: http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic