You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Ate Douma <at...@douma.nu> on 2009/01/19 10:03:37 UTC
Wicket Portlet 2.0 support - status
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
Re: Wicket Portlet 2.0 support - status
Posted by Ate Douma <at...@douma.nu>.
Thijs wrote:
> Hi Ate,
>
> Your email sounds very promising. I'm very happy that Portlet2 is going
> into Wicket.
>
> In your email you mentioned Liferay using Sun's portlet-container.
> Liferay doesn't by default use the Sun portlet container implementation,
> but it's own. We spoke to Brian Chan (Liferay's CEO) about this. They
> are probably not going to put the SUN implementation as their current
> default because of performance issues with that implementation. This is
> of interest for Wicket working in Liferay.
OK, I wasn't aware of that.
I'll need to add Liferay too then to the list of portals to validate against (or maybe you can do that?).
>
> I have some updates on the portlet 2 patch based on some experience I
> have with Liferay over the last few months of trying to get everything
> to work. (I've also tested this with pluto trunk)
> I haven't posted any updated to WICKET-1620 as I wasn't really
> successful. But I had some luck last week and was planning on uploading
> a new version of Antony's patch with some updated things.
>
> These include.
> * use of RequestDispatcher.forward when using serveResource instead
> of RequestDispatcher.include. (this fixes resourceServing in Liferay's
> portlet-container implementation)
Check, same thing required for Pluto (not for Jetspeed or SUN OpenPortal though which both plug in a custom BufferedResponseWrapper to
handle this)
In my local changes I already did the same.
Not 100% sure yet though if using a forward the right way to solve this: when using a forward there is no way of further handling the
response after that... And, from within Wicket there might be cases when a redirect could be issued. Currently, this is handled within the
WicketPortlet by simply reinvoking Wicket during the same request (and ignoring any response output so far). When using a forward though
this won't be possible anymore. Its not clear yet to me how important that use-case might be (for serverResource requests), but its
something to keep in mind. It might be necessary to use the same solution as applied by Jetspeed and OpenPortal to deal with this *within*
Wicket to keep it independent from portlet container implementations.
Note: for Action and Render requests this will be required anyway and I'm already working on that.
> * use of the get/setResourceId for resource-requests instead of the
> render-parameters.
Cool, I haven't come to that part of the spec. If you have supportive code for Wicket on that, please share :)
> * displaying errorpages correctly in portlet mode.
Cool again, looking forward to it :)
>
> But I understand from your email that you are not going to commit
> Antony's patch, just an evolved version of mine (without the event stuff)?!
> So I was wondering if you would you still like to see my modifications?
Yes on both accounts. The patches from Antony concerning Event handling definitely will become important for Wicket 1.5, but they are too
invasive in the Wicket core functionality (in their current form that is) to target Wicket 1.4
> And if yes, shall I upload them in an updated version of Antony's patch
> or do you have a patch that does not contain all the event stuff?
If possible I'd prefer a slim patch without the Event handling. I'll create a patch of my local changes shortly as a separate patch file to
WICKET-1620 which you than can to merge your changes with.
Regards,
Ate
>
> best regards
>
> Thijs
>
> ps. on of the things I noticed is that pluto isn't setting
> (resource)response headers correctly, as they are not (always)returned
> to the client. I haven't looked at this closely enough to know if this
> is a known issue or not. I'm happy to provide details at your request.
>
> On 19-1-2009 10:03, Ate Douma wrote:
>> 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
>
>
Re: Wicket Portlet 2.0 support - status
Posted by Thijs <vo...@gmail.com>.
Hi Ate,
Your email sounds very promising. I'm very happy that Portlet2 is going
into Wicket.
In your email you mentioned Liferay using Sun's portlet-container.
Liferay doesn't by default use the Sun portlet container implementation,
but it's own. We spoke to Brian Chan (Liferay's CEO) about this. They
are probably not going to put the SUN implementation as their current
default because of performance issues with that implementation. This is
of interest for Wicket working in Liferay.
I have some updates on the portlet 2 patch based on some experience I
have with Liferay over the last few months of trying to get everything
to work. (I've also tested this with pluto trunk)
I haven't posted any updated to WICKET-1620 as I wasn't really
successful. But I had some luck last week and was planning on uploading
a new version of Antony's patch with some updated things.
These include.
* use of RequestDispatcher.forward when using serveResource instead
of RequestDispatcher.include. (this fixes resourceServing in Liferay's
portlet-container implementation)
* use of the get/setResourceId for resource-requests instead of the
render-parameters.
* displaying errorpages correctly in portlet mode.
But I understand from your email that you are not going to commit
Antony's patch, just an evolved version of mine (without the event stuff)?!
So I was wondering if you would you still like to see my modifications?
And if yes, shall I upload them in an updated version of Antony's patch
or do you have a patch that does not contain all the event stuff?
best regards
Thijs
ps. on of the things I noticed is that pluto isn't setting
(resource)response headers correctly, as they are not (always)returned
to the client. I haven't looked at this closely enough to know if this
is a known issue or not. I'm happy to provide details at your request.
On 19-1-2009 10:03, Ate Douma wrote:
> 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