portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: [Fwd: Wicket Portlet 2.0 support - status]
Date Mon, 19 Jan 2009 20:53:55 GMT
Eugene Fabrikant wrote:
> 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?
I'm working on the Portlet 2.0 support for Jetspeed-2 which will be committed against trunk
as soon as I have a feature properly tested and 
validated. The Wicket Portlet 2.0 support of course will go against the Wicket trunk itself.

> 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

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

View raw message