This portlet messaging library is intended for situations when:
You want to build an application out of several interacting portlets (e.g. a portlet which presents a list or index, and a number of portlets which display information about the selected item)
You've read this Tip on java.net and decided that the PortletSession is the way to go (if you wanted one of the other methods, have a look at Limitations in the Documentation)
You can't simply hardcode the messaging using APPLICATION_SCOPE session variables with known names, because:
Maybe you want many instances (windows) of the same portlet on the same page, or different pages, with each instance talking to different portlets
Maybe you want the user to be able to dynamically add new portlet instances (windows), and configure the 'wiring' of messages between portlets.
Maybe you want portlets in different portlet applications to communicate.
This is version 2.4 of a slightly more complicated messaging system, implemented for the Discovery Net project. Please let me know if you find it useful, or have any comments/advice/bugfixes that may make it better. The source is available and you're welcome to modify/use it however you like. It's licensed under the Apache License, Version 2.0.
Bugfixes for use with recent JBoss Portal builds (>22 June 06): fixed support for messages with blank namespaces, and for Edit mode on some of the test portlets.
Better example portlets - Portlet1 and Portlet2. They provide a quick way of testing messaging, and also act as a mini-tutorial.
Practical change for users: the library now uses commons-logging for debug messages. This adds a dependency to your portlet app using the messaging library - though your portal server probably already has it.
Cross-context messaging simple EJB example now working and tested on Geronimo 1.0, JBoss 3.2.7, and JBoss 4.0.2.
Simple messaging model: message names in session must be hardcoded into the portlets
Advanced messaging model: message names in session do not need to be hardcoded. A Message Centre keeps track of all the mappings between local message names and global message names, allowing dynamic reconfiguration of message 'routes' by the administrator or the portal user.
