File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Portals and Portlets and the fly likes Remote Portlets + WSRP + JSR 168 Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » Portals and Portlets
Bookmark "Remote Portlets + WSRP + JSR 168" Watch "Remote Portlets + WSRP + JSR 168" New topic
Author

Remote Portlets + WSRP + JSR 168

Rohit Mehra
Greenhorn

Joined: Mar 09, 2011
Posts: 1
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

Joined: Mar 06, 2001
Posts: 13459

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
 
Don't get me started about those stupid light bulbs.
 
subject: Remote Portlets + WSRP + JSR 168
 
Similar Threads
Choosing Page Flow Portlets or Java Portlets - Weblogic
Websphere Portal - Test 399
wiki portlet ?? Sun Java Portal Server
Query on JSR 168 Struts portlet
Portal and portlet in WebSphere and remote struts application in weblogic