[ http://issues.apache.org/jira/browse/JS2-208?page=comments#action_59049 ] Ate Douma commented on JS2-208: -------------------------------
Peter, I finally found a short time today for a first look at your code and documentation. I must say, I'm impressed by the completeness and scope. But, I haven't had time for testing so this is yet only based on a short code review ;-) I do have already a few questions for you: - Are you planning/able to update the code to the J2 cvs-head codebase? As it is currently based on the J2 2.0M1 codebase I would need to go back to that before I would be able to test it, and although possible its not something I prefer. - Do you have any showcase portlets (code) available? It would help (me) a lot to have a working example to play with. - I noticed you had to modify the Pluto PortletContainer(Impl) to trap its redirecting. Have you considered providing a wrapped request to Pluto which might be able to do the same (I'm not sure, just asking). I don't like the idea to have to hack Pluto if its isn't absolutely necessary. - I like the general idea of translating a PortletEvent to an (additional) ActionRequest for a targeted Portlet as for that Portlet it is as if it is invoked by the user directly. What I'm not sure about yet is how you handle ActionResponse.setRenderParameter() calls done by the thus invoked Portlet: will new renderParameters be set on the eventually produced RenderURL? It looks like the initial RenderURL produced after the ActionRequest from the Portlet firing the first PortletEvent prevails but I'm not sure. I think that if a new ActionRequest is invoked as result of a PortletEvent the formal behavior of the Portlet API must be maintained, including effective setRenderParameter calls. - You implemented the invocation of a new ActionRequest using real redirects. Might it be possible to just synthesize a new ActionRequest without the need for a client side redirect? It might make state handling much easier and lighter: maybe use ThreadLocals instead of storing state in a HashMap keyed on SessionId as you do now. Also, by intercepting the (initial) ActionRequest, you then also wouldn't need to hack the Pluto PortletContainer but first process all the PortletEvents before letting Pluto perform the final redirect. I'll try to find some more time this weekend to delve deeper into your code. Ate > Inter-portlet Communication > --------------------------- > > Key: JS2-208 > URL: http://issues.apache.org/jira/browse/JS2-208 > Project: Jetspeed 2 > Type: New Feature > Components: Assembly/Configuration, Components Core, Container, Other, > Struts Portlet > Versions: 2.0-M1 > Reporter: Peter Meier > Attachments: jetspeed-2-diff.zip, portlet-event.zip > > As already announced elsewhere I would like to submit a working solution for > inter-portlet communications between portlets that do not belong to the same > portlet application. > The implemented portlet communication is not part of JSR168 and therefore a > proprietary extension. It utilises the JSR168 portlet API, though. > Inter-portlet communication is achieved through portlet event notifications. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
