First patch for portlet 2.0

Fixed:
When in a ajax call (ResourceRequest) and we do setResponsePage(WebPage.class), and WebPage.class is mounted, the current implementation doesn't break out of the ResourceRequest, it just creates a new ResourceURL. When this happens, I only get the Markup of the portlet back, not the whole portal page.

By forcing a RenderUrl when a requestTarget instanceof IBookmarkablePageRequestTarget

Hi Thijs, what sort of percentage complete would you say the 286 support is at?

Well, it's basically Ate's portlet 1 specs implementation with the addition of resourceserving, setting cookies and the like.
So almost al you can do in a normal wicket application should work in a portlet as well, so: ajax, forms, serving files, etc should all work. Within the portlet specifications obviously.

I haven't tested yet but probably public renderparameters will work as well. A colleague was testing this just last week, however I haven't heard any results yet.

But IPC through event handling is not build in yet. And I have no idea when I have time to really dive into this.
And there is probably some other things missing as well.

Also this patch replaces the portlet 1 implementation, so it's not backwards compatible and there are some discussions if we should have both versions implemented.

Cool, thanks for the info.
Isn't Ate's portlet 1.0 support already in Wicket trunk?
Also, what version of wicket is this patch generated against?

Yes portlet support was introduced in 1.3

This patch is against revision 657619 of wicket-1.4 trunk version, but because this patch is from May, I'm not sure it will patch cleanly on current truck.
We are still on 1.3 so I haven't updated 1.4 for a long time

So just to clarify - although this patch is from May, does it represent the current state of the nation for wicket 286 support?
Are you working on this at all anymore?

Yes this is the latest version of this patch. A Wicket-1.3 version of this patch is what we are working with in our product.

At the moment I'm not doing any enhancements to this patch, because right now it is doing what we want and I don't have/get time to add any new features.

I see. Are you able to provide that patch as well? Our company will also be working with Wicket and 2.0 portlets and have resource to help improve the project.
I.e. I want to help out, and would like to follow the same direction as you.

FYI - related forum thread:
http://www.nabble.com/Portlet-2.0-implementation-in-Wicket-td17187909.html

Working eventing system as described on the mailing list:
http://www.nabble.com/forum/ViewPost.jtp?post=20227405&framed=y

Only known issue at this stage is the requirement to not be sitting on a portlets home page for it to receive an event.

I will also include an example project.

example project

please note that these two patches are in working draft, and I have uploaded them just to share my work. There is still cleanup, fixing and documenting to be done. There is also some unused code and commented out code left in the patch for purpose of demonstrating alternative implementations that I didn't end up using.

This is also intended to fuel conversation about the chosen implementation.

The patches are inclusive of the original work, so only apply one.

There is also a lot of javadoc done in the patch on Wicket core, so that could be committed/reviewed separately.

FYI, Also with all my stubborn focus on trying to get wicket to redirect completely from the home page, I've introduced redirect loops under certain conditions.

this version of the patch fixes the issue with the target portlet not processing the event request when sitting at a bookmarkable page

Remaining issue is that events are processed in the render phase, which is incorrect as they should be processed in the event request, so that other events can be triggered (render cycles cannot trigger events).

Shiny new event implementation using a custom RequestTarget - much better, less hacky and more importantly events are now processed in the eventrequest phase, and you can raise new events in response.

However I seem to have bumped into what might be a bug in pluto:
https://issues.apache.org/jira/browse/PLUTO-522

So this is seems now to be functionally complete. I have a few clean ups on my todo list and need to wax the code still. At this stage I will still leave in the remnants of alternative implementations so they can be discussed.

the example project.
leaving in the old patches so the changes in implementation can be compared.

Antony,

Sorry for not getting back on this earlier but today I spend a few hours reviewing the patch.
Well, the fact that its a big mix of both general javadoc and comment improvements (many unrelated to this issue) as well as the portlet2.0 enhancements/changes
made it very time consuming to see the wood from the trees.

So, I've spend my time trying to separate these two, as well as cleanup some erroneous changes and/or adding missing things like required License Headers.
The javadoc and comment changes I have now committed, so that only the real functional changes and enhancements for portlet2.0 remain.
Of those remaining changes, I created a new patch, WICKET-1620-portlet2.0.patch, and attached it.

If you have more (independent) javadoc/comment improvements coming up (great!), it would be better to provide those separately, not mixed up within patches for this issue.

Sorry to say that my time is now up for today, and next week I'll be abroad again for a client.
I'll try to review the remaining patch during the evenings next week though.

For now, one thing I encountered trying to build with the patch: there seems to be some errors in the PortletEvent Generics setup.
If I execute (from the wicket project): mvn clean install, I get the following compilation errors:

wicket/src/main/java/org/apache/wicket/protocol/http/portlet/events/IPortletEventService.java:[44,79] type parameter T is not within its bound
wicket/src/main/java/org/apache/wicket/protocol/http/portlet/events/IPortletEventService.java:[53,82] type parameter T is not within its bound
wicket/src/main/java/org/apache/wicket/protocol/http/portlet/events/BasicStringPortletEventListener.java:[23,46] type parameter org.apache.wicket.protocol.http.portlet.events.BasicStringPortletEvent is not within its bound
wicket/src/main/java/org/apache/wicket/protocol/http/portlet/events/PortletEventService.java:[58,38] type parameter T is not within its bound
wicket/src/main/java/org/apache/wicket/protocol/http/portlet/events/PortletEventService.java:[72,95] type parameter T is not within its bound

So it would be great if you could try to get that fixed first and provide an updated patch.

Thanks for having a look Ate. But my intention was for you to reply to the emails to the dev list about the implementation - you did not have to do all this work yourself, as I was going to do it. But too late now I guess.

Before you go about understanding any of the code I wrote, let alone cleaning it up or fixing those errors, I think it would be most valuable to actually discuss the implementation, as it's not finalised, don't you think?

I agree the discussion needs to be about the design of the solution, but for that I definitely need to take a look at the proposed implementation too.
For me it was to cumbersome to try to see the core Wicket changes (besides the obvious portlet specific ones) between all the javadoc changes.
And I also like to see the example event portlet actually working in Pluto too!
I got it running (by not doing a mvn clean but just take the Eclipse compiled sources) and fixing PLUTO-517, but then got event payload loading errors instead

Anyway, as I said I'll try to look into both the code and the design questions next week in the evening hours and get back to you as soon as I've got a better overview.

Yes there's still issues to iron out - the path on the issue is out of date now.
I highly recommend you look at the design questions, before you look at the code. As I've said else where, that patch contains 3 different implememtations.

Sorry Ate, to what does the patch apply cleanly to? I'm having some trouble patching trunk with it.

ho ho ho, merrrrry xmas! ahhh - feels so good to delete code

Here's the latest in patchy goodness. I did a svn update on my working copy, and tidied up the patch, removing extra code and even fixing and improving parts of it. i.e. this patch is against trunk, and is inclusive the last last patch.

• improved implementation with working event to event responses,
• improved javadoc
• better state aware response object retrieval
• fixed event name requirement
• better example with both event to event response and no even to event response links

see here: http://stubbisms.wordpress.com/2008/12/25/aaaaand-were-done/ for a short explanation of the implementation

Let me know if you have any problems please!

Could it be that you made a small error in the StateAwareServletResponseWrapper?

public StateAwareSevletResponseWrapper(HttpServletResponse response,
WicketResponseState responseState, PortletResponse portletResponse)

this tries to cast a HttpServletResponse to a portlet response. Shouldn't it be:

public StateAwareSevletResponseWrapper(HttpServletResponse response,
WicketResponseState responseState, PortletResponse portletResponse)

Hi there! FYI I'm tripping around the South of Europe ATM and won't be
back on regular email access until February - so hold tight!

–

Everyone interested in the WicketPortlet support for Portlet API 2.0, please checkout the new subtask WICKET-2058 which I created to only do a upgrade to Portlet API 2.0, but not add any new features.

Hi there!

Currently I'm not able to apply the patch over the TRUNK SVN. Antony, It will be great if you check it, please.

Latest patch I tried is WICKET-1620-portlet2.0-tight.patch

Should I apply all or does this patch include everything?

Also, I saw you included A LOT eclipse workspace modifications in your patch. It will be also great if you remove this stuff and just go with straight maven.

I'm doing intensive work with this and jetspeed so maybe I can help also a little bit.

Thank you for your work.

ah yes - great to hear some interest in this! Yes - this patch is of course out of date. We haven't been active in this area since December '08. However, not that 1.4 is out, I plan on upgrading the patch and working with the guys to get it into trunk, or at least a branch. However, it's not at the top of the todo list, so you may have to either update it yourself or be patient

Hi Antony,

I'm currently trying to implement portlet intercommunication with events. I was using public render parameters but
now it's too complex to approach the problem in that way.

What's the current status of this issue? Do you think trunk 1.5 has events implemented?

Thank you!

No, I don't think any of this code is in trunk. However, it worked very well. It is quite out of date now, and will need changes to be applied cleanly to trunk.

However, I have no interest in developing it further as I have moved on from my previous position. However, I can be contacted through sharca.com if you're interested in funding development.

Cheers!

P.s. I'm also out of the loop on what the Wicket team plans for eventing.

wicket 1.5 (trunk) may not come with portlet support.

the goal for 1.5 was to rewrite the url/request handling because it was very fragile. we are almost done with the code and will probably have 1.5 milestone 1 soon. however, since we do not have any active committers who also work with the portlet api none of that code is in 1.5 and the old code from 1.4 was not portable because the api is completely changed

. it would be great to get feedback from Ate and other portlet developers about the current code in 1.5 and how pluggable it is with respect to the requirements of the portlet api.

if we do not find someone who is willing to devote the time to build the portlet support into the new code it may not come with it.

Igor - that sounds very exciting! Do you have handy any documents or conversations around the new url/request handling code? Or shall I just dive in and take a tour?

ok, I've found http://old.nabble.com/-wicket-1.5--url-handling-refactor-preview-ts25723884.html - having a read...

we will not be providing portlet support until we have an active committer that wants to maintain it

Hi
I can see that portlet support did not make it into the current state of 1.5.

But these patches were done one 1.4, is it not possible to get these patches done on the 1.4 branch? Or is this patch not properly tested yet.

I just want to know, because we are moving to a portal environment and would love to use wicket going forward, (even if it is just 1.4 for now)