[
https://issues.apache.org/jira/browse/WICKET-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12668449#action_12668449
]
Ate Douma commented on WICKET-2058:
-----------------------------------
Hi Thijs,
I reviewed your changes. Note: I haven't yet tested this but will do so this
afternoon.
I also noticed your patch-patch didn't contain the deletion of
PortletActionServletResponseWrapper.java and
PortletRenderServletResponseWrapper.java anymore.
As these are no longer used, I expect deleting them is OK for you, or did you
intentionally not delete them in your patch-patch?
For now, a few quick comments/questions
1. using resourceID seems like a smart and more efficient solution, so +1 for
now
2. redirecting on runtime exceptions when in a Portlet:
Can you explain what exact effect / page navigation this will result in?
You wrote above this will cause the portlet to redirect to the homepage(?)
and doesn't display the errorpage!
So, how then can/should a Portlet (or maybe the Wicket application from a
Portlet) configure/handle custom error page specific for usage within a Portlet
context?
Is there an example provided by wicket-examples which can show the effect
of this change and/or do you have a quick example available?
> Upgrade Wicket Portlet Support to only use native Portlet API 2.0
> ------------------------------------------------------------------
>
> Key: WICKET-2058
> URL: https://issues.apache.org/jira/browse/WICKET-2058
> Project: Wicket
> Issue Type: Sub-task
> Components: wicket-portlet
> Affects Versions: 1.4-RC1
> Reporter: Ate Douma
> Assignee: Ate Douma
> Fix For: 1.4-RC2
>
> Attachments: wicket-2058-patch.patch, wicket-2058-patch.txt
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
