[Fwd: Wicket Portlet 2.0 support - status]

[Ate Douma <at...@douma.nu>]

-------- Original Message --------
Subject: Wicket Portlet 2.0 support - status
Date: Mon, 19 Jan 2009 10:03:37 +0100
From: Ate Douma <at...@douma.nu>
Reply-To: dev@wicket.apache.org
To: Wicket Development <de...@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

Re: [Fwd: Wicket Portlet 2.0 support - status]

[Ate Douma <at...@douma.nu>]

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 <at...@douma.nu>
>> Reply-To: dev@wicket.apache.org
>> To: Wicket Development <de...@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

Re: [Fwd: Wicket Portlet 2.0 support - status]

[Eugene Fabrikant <ef...@bluenog.com>]

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 <at...@douma.nu>
> Reply-To: dev@wicket.apache.org
> To: Wicket Development <de...@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