portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eugene Fabrikant <efabrik...@bluenog.com>
Subject Re: [Fwd: Wicket Portlet 2.0 support - status]
Date Mon, 19 Jan 2009 14:48:55 GMT
Hi Ate,

I just wanted to clarify the part about porting the Portlet 2.0 patches
and testing against Jetspeed-2, is that the Jetspeed trunk or a specific
branch?

Thanks,

Eugene


Ate Douma wrote:
>
>
> -------- Original Message --------
> Subject: Wicket Portlet 2.0 support - status
> Date: Mon, 19 Jan 2009 10:03:37 +0100
> From: Ate Douma <ate@douma.nu>
> Reply-To: dev@wicket.apache.org
> To: Wicket Development <dev@wicket.apache.org>
>
> Hi all,
>
> Its been a long time before I had any time to work on the Wicket
> Portlet support but I'm (part time) back in the game now.
> Luckily Thijs Vonk and Antony Stubbs already have put a lot of effort
> into this too, especially in getting Wicket running in a Portlet 2.0
> container and provided several patches for doing so, see
> https://issues.apache.org/jira/browse/WICKET-1620
>
> The current Wicket Portlet 1.0 support, leveraging some custom
> extensions provided by Portal Bridges (ServletContextProvider and
> PortletResourceURLFactory interfaces), while generic of nature and
> technically supportable by any Portlet Container, have turned out to be
> difficult to get supported or implemented by other portals except
> Jetspeed-2, especially the PortletResourceURLFactory interface
> (ServletContextProvider *is* supported by all/most Portlet containers
> nowadays).
>
> Thijs Vonk and Antony Stubbs therefore have concentrated on replacing
> the usages of these extensions (which from the beginning were
> intentionally temporary anyway) by the now available Portlet 2.0
> features (Thijs), as well as adding support for new Portlet 2.0 features
> (Events, Antony).
>
> The chosen solution, as has been discussed on this list before, is to
> *replace* the current Portlet 1.0 with Portlet 2.0 support *only*.
> This means that, once this upgrade is done, Wicket will *not* work
> anymore on only Portlet 1.0 supporting portlet containers!
> As I have expressed on this list before, I fully support that change,
> and as most portlet containers nowadays do have Portlet 2.0 support
> (Jetspeed-2 being an exception, but we're in the process of adding
> that very soon now), I don't see that as a major issue anymore.
>
> FYI: I've tested (part of) the patches from Thijs and Antony already
> and with reasonable success although I did have to make some changes.
> And (for now) I limited this to the existing Wicket Portlet support
> features. I did not yet merge and test the Portlet Event features as
> added by Antony as those really require core Wicket changes which I
> currently still consider out of scope for Wicket 1.4 at least.
> Furthermore, the Event handling changes need further discussion and
> technical changes which I will come back on in another email sometime
> later (for one, those changes currently always require a Portlet API
> to be available on the classpath, even for plain web applications).
>
> I've already got the (adapted) basic Portlet 2.0 patches more or less
> working on Pluto, Jetspeed-2 and SUN OpenPortal container (e.g. the
> container that Liferay also uses). On JBoss and eXo these still do not
> work properly. Although I haven't dived into why not (as I'm only a
> Pluto and Jetspeed-2 committer, not knowledgeable on those other
> containers), I think I already figured out some potential causes for
> this.
>
> The handling of Portlet/Servlet request and response, especially with
> regard to Cookies, Header parameters in general, content type and
> buffering is not yet implemented correctly as required by the Portlet
> 2.0 specification (which is *very* tricky in this regard).
> Formally, none of the above (response) interactions concerning
> Cookies, Header parameters and content type setting is supported from a
> RequestDispatcher.include, but WicketPortlet currently (also with the
> patches) does *need* to leverage an include call to be able to support
> redirect handling from within Wicket itself.
>
> As I'm currently working on the (proper) Portlet 2.0 API
> implementation in both Pluto and Jetspeed-2, I'm quite on top of these
> spec
> features and plan to (also) validate those against Wicket Portlet 2.0
> support. And, for further compliance and support validation, I'll keep
> on testing Wicket against SUN OpenPortal container, JBoss Portal and
> eXo Portal too.
>
> Once I get the *current* Wicket Portlet 1.0 support properly working
> again in these Portlet 2.0 containers (except for issues where they
> themselves are not properly following the spec as I've already saw in
> some area's with SUN Open Portal), I'd like to commit the upgrade to
> Wicket Portlet 2.0 support against the Wicket trunk, e.g. targeting
> Wicket 1.4 release...
>
> The changes I expect needed for this will *not* affect any core Wicket
> functionality, so far all these changes will be contained within the
> portlet specific classes and/or within code blocks executed within a
> portlet environment only.
> And, the dependency on Portlet 1.0 API will need to be upgraded to the
> 2.0 API and the dependency on the Portals Bridges Common jar will no
> longer be needed.
>
> New Portlet 2.0 features like the Event handling as provided by Antony
> will need further discussion as I indicated above and for now I
> expect those probably better wait until work on Wicket 1.5 starts.
>
> Please stay tuned, I'll follow up on this as soon as possible.
>
> Regards,
>
> Ate
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>



---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org


Mime
View raw message