Win a copy of React Cookbook: Recipes for Mastering the React Framework this week in the HTML Pages with CSS and JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Rob Spoor
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Junilu Lacar
  • Tim Cooke
Saloon Keepers:
  • Tim Holloway
  • Piet Souris
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
  • Frits Walraven
  • Himai Minh

Remote Portlets + WSRP + JSR 168

Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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?
Posts: 13459
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
a wee bit from the empire
the value of filler advertising in 2021
    Bookmark Topic Watch Topic
  • New Topic