[WICKET-2058] Upgrade Wicket Portlet Support to only use native Portlet API 2.0

• Type: Sub-task
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.4-RC1
• Fix Version/s: 1.4-RC2
• Assignee: Ate Douma
• Reporter: Ate Douma
• Created: 28/Jan/09 13:08
• Updated: 17/Dec/13 19:17
• Resolved: 31/Jan/09 10:58

Description

WICKET-1620 is an overall issue for provide full blown Portlet API 2.0 support to Wicket, including new features like Portlet Eventing.
As those new features still will require further discussion and require some critical changes to the core Wicket API, the target for WICKET-1620 is currently set for version 1.5

However, as the current Portlet 1.0 support in Wicket turned out not very well supported by other Portals than Apache Jetspeed-2.
For Portlet 1.0 containers, a few custom, Portal SPI interface based enhancements, as defined by the Apache Portals Bridges project, need to be provided by a portal (container) to enable Wicket in a Portlet environment.
This turned out to be more difficult then expected.

But as Portlet API 2.0 now is generally available for all/most portlet containers, those custom enhancements are no longer needed!
The goal has been from the outset to replace these custom interfaces with native Portlet API 2.0 features as soon as it would be generally available.

As the latter is now the case, I created this separate subtask of WICKET-1620 to only upgrade the current Wicket Portlet features to Portlet API 2.0
So, no new features, nor any real changes needed to the Wicket core.

This way, the impact of this upgrade can be done more or less "painless" and without any side-effect to Wicket core itself, but then make it much easier to enable Wicket generically in a Portlet (2.0) environment.

I've taken the initial patches provided by Thijs Vonk, added some general improvements from the extensive patches from Antony Stubbs (but not all, and none of the "new" features) as starting point.

After adding several further enhancements and fixes and even a few workarounds for incomplete/incorrect Portlet API 2.0 implementations of some containers (e.g. OpenPortal, JBoss Portal), I've now finally a new patch available with which Wicket Portlet works great on the following Portlet API 2.0 containers: Apache Pluto 2.0 (trunk development), Apache Jetspeed-2 2.2 (trunk development), Sun OpenPortal Container 2.01_01

I've also tested against Exo Portal (exo-pc-2.0.5-tomcat) and JBoss Portal 2.7.

Exo Portal Container 2.0.5 however turned out to not work well, it looks like some serious Portlet API 2.0 requirements are not working yet

JBoss Portal 2.7 already was much better, plain Wicket features seems all to work fine, but Ajax support still doesn't work.
I put a few temporary "workarounds" for JBoss Portal quirks (strange windowId format containing embedded '/' characters, and some UnSupportedOperationExceptions thrown on Spec required API methods!).
And for Sun OpenPortal I also needed to put in a temporary workaround, but those are rather minor issue which (AFAIK) don't really limit the usage of Wicket.

As I understood from Thijs Vonk he's primarily working with Liferay Portal which I haven't had time yet to test against myself. I hope and expect Thijs will look into that.

I'll attach my new patch to this issue shortly. Please all review and test.

As building a Wicket 1.4-RC2 release is scheduled (anew) for this weekend, I'd like to get some confirmation from especially Thijs if/how this patch works out on Liferay.
If nothing turns out to be seriously broken, I plan to commit this to wicket trunk before 1.4-RC2 is created so that everyone interested in WicketPortlet will have a good new baseline for further improvements and testing.

Issue Links

• relates to: WICKET-2078 WICKET-2058 does not support IBM Websphere Portal Server 6.1