Inter-portlet Communication

• Key: JS2-208
• Type: New Feature
• Status: Closed
• Resolution: Won't Fix
• Priority: Major
• Assignee: Unassigned
• Reporter: Peter Meier
• Component/s: Assembly/Configuration, Components Core, Container, Other, Struts Portlet
• Affects Version/s: 2.0-M1

Description

As already announced elsewhere I would like to submit a working solution for inter-portlet communications between portlets that do not belong to the same portlet application.
The implemented portlet communication is not part of JSR168 and therefore a proprietary extension. It utilises the JSR168 portlet API, though. Inter-portlet communication is achieved through portlet event notifications.

Comments

[Peter Meier]

Attached are two zip files, which contain (a) the portlet event notification package, and (b) the changes that need to be applied to Jetspeed-2. All changes are highlighted and commented.

Please read docs/description.html in jetspeed-2-diff to begin with.

I appreciate any comments or feedback.

[Ate Douma]

Peter, I finally found a short time today for a first look at your code and documentation.

I must say, I'm impressed by the completeness and scope.
But, I haven't had time for testing so this is yet only based on a short code review ;-)

I do have already a few questions for you:

- Are you planning/able to update the code to the J2 cvs-head codebase?
  As it is currently based on the J2 2.0M1 codebase I would need to go back to that
  before I would be able to test it, and although possible its not something I prefer.
- Do you have any showcase portlets (code) available?
  It would help (me) a lot to have a working example to play with.
- I noticed you had to modify the Pluto PortletContainer(Impl) to trap its redirecting.
  Have you considered providing a wrapped request to Pluto which might be able to do the
  same (I'm not sure, just asking). I don't like the idea to have to hack Pluto if its isn't
  absolutely necessary.
- I like the general idea of translating a PortletEvent to an (additional) ActionRequest for
  a targeted Portlet as for that Portlet it is as if it is invoked by the user directly.
  What I'm not sure about yet is how you handle ActionResponse.setRenderParameter() calls done
  by the thus invoked Portlet: will new renderParameters be set on the eventually produced
  RenderURL?
  It looks like the initial RenderURL produced after the ActionRequest from the Portlet
  firing the first PortletEvent prevails but I'm not sure.
  I think that if a new ActionRequest is invoked as result of a PortletEvent the formal behavior
  of the Portlet API must be maintained, including effective setRenderParameter calls.
- You implemented the invocation of a new ActionRequest using real redirects. Might it be
  possible to just synthesize a new ActionRequest without the need for a client side redirect?
  It might make state handling much easier and lighter: maybe use ThreadLocals instead of storing
  state in a HashMap keyed on SessionId as you do now.
  Also, by intercepting the (initial) ActionRequest, you then also wouldn't need to hack the Pluto
  PortletContainer but first process all the PortletEvents before letting Pluto perform the final
  redirect.

I'll try to find some more time this weekend to delve deeper into your code.

Ate

[Peter Meier]

Attached are two simple inter-portlet communications demos, one using JSR 168 portlets, the other using Struts portlets. They are intended to highlight the principles of portlet event notifications and to show how to use the Portlet Event API.
Contained are four portlets, which are arranged in three portal pages in a mix and match fashion.

[Ate Douma]

Peter, I think you forgot to attach the demos... ;-)

[Peter Meier]

Here is the promised demo. I've had to overcome some issues with our firewall to let me upload things.

[garpinc]

What's the latest with this. Will it make it for M3?

[Peter Meier]

I have an updated version for Jetspeed-2 M2 available, I will submit it in a couple of days or so.
Peter.

[garpinc]

Shouldn't you submit it for latest head version?

[Peter Meier]

Please keep in mind that inter-portlet communication is not part of the official Jetspeed-2 code base (yet ;-). As a non-committer, I need a stable reference point I can develop against. The latest head version is a moving target. Every time a committer checks in code, it might break the IPC solution.
Peter

[garpinc]

Perhaps then maybe instead you should check out by date. That will be stable if you pick a date prior to today. That way the integration effort required by the committer team will not be great and it will be far more likely they will integrate it before M3.

[Sven Thiergen]

I took Peter's example and integrated it against the current CVS HEAD. It was possible almost without changes, except that the "Fragment" type in "NotificationValveImpl" and "PortletStackValveImpl" needed to changed to "ContentFragment". This traces down to "request.getPage().getRootFragment()" which I changed to "...getRootContentFragment()". Hope this is no problem; I am unaware of real meaning of the methods.

My first example did not work, but it was the first try so maybe I am doing something wrong. I can put in another day or two to get the thing working.

Regarding design:
The changes in the Pluto classes probably really need to change. They introduce a dependency to Jetspeed2 (usage of class "BasePortletEvent") which certainly isn't possible. Fortunately, only a static method is used which swaps around a parameter from a Map into a HttpServletRequest.

Ate suggested to synthesize an ActionRequest; instead of doing a real Redirect. Seems like the best solution regarding performance and cleanliness; so the Pluto code has not to be touched at all. Can someone give me some hints how to do this?

[Michael Lipp]

Jonathan Hawkins ([e-mail]) just sent me a pointer to http://www.doc.ic.ac.uk/~mo197/portlets/portlet_messaging/index.php. Maybe this library should be considered when the issue is revisited (just saving information).

[Ate Douma]

Resolution will take too much time to make it for the 2.1 release

[Ate Douma]

This issue is outdated now, sorry we never got around really evaluating using this (or something else).
With Portlet API 2.0, this feature is now (more or less) covered by the spec.