Re: Portlet howto

[Charles CHAHBAZIAN]

Hi Ate, Ate Douma a écrit : Charly wrote: Hello, I have the beginning of a solution ! Cool ! My code is based on Liferay's struts support with some adaptations. At this time, Guestbook portlet sample is ok, and I've made a modification in wicket to get Navomatic and other bookmarkablePage working. The main point is that Liferay want a new HttpServletRequest (from theirs object) in ServletContextProvider implementation of ServletContextProvider and we must copy the request's parameters from the original request to the new one. Weird, but I guess it is something Liferay specific. You're right. Because if I keep the same HttpServletRequest, I have a ClassCastException later because Liferay use these specific objects... I translate also the "_wu" (WicketPortlet.WICKET_URL_PORTLET_PARAMETER) parameter into differents parameters Why? The WicketPortlet dispatches to the servlet/filter using this url, so the underlying web container (e.g. catalina) should already provide the query string parameters as request parameters (as required by the servlet spec). You can have a look to my 3 classes at the end of this mail. I notice that you don't set the provided Map portletArg arguments on the created PortletURLImpl in createResourceURL method. You probably should... I tried that solution first. In that case, the url looks like that : http://localhost:8080/user/joebloggs/3?p_p_id=NavomaticApplication_WAR_wicketexamples&p_p_action=0&p_p_state=normal&p_p_mode=view&p_p_col_id=column-1&p_p_col_count=1&_NavomaticApplication_WAR_wicketexamples__wuview=%2Fnavomatic%2F%3Fwicket%3AbookmarkablePage%3D%253Aorg.apache.wicket.examples.navomatic.Page2 But the WebRequestCodingStrategy (at line : 518) use the request.getParameter() and on my debug sessions i saw that the portletArgs i've put in the PortletURLImpl parameters are available in the queryString but not in the parameters of the request ... (looks strange for me too, it seems to be a liferay's bug)   I've got a problem for all bookmarkablePage, because the argument are encoded by Wicket, and Liferay encode it second time. Liferay shouldn't be doing that: you should get back the parameters previously set on a PortletURL exactly the same. Seems like a Liferay bug to me. About that question, as you can see in the sample url I've put, we have wicket%3AbookmarkablePage%3D%253Aorg.apache.wicket.examples.navomatic.Page2 you can see that the there are 2 encoding : 1) wicket set the parameter from ":org.apache.wicket.examples.navomatic.Page2" to "%3Aorg.apache.wicket.examples.navomatic.Page2" 2) Liferay encode the "%" character to "%25" When Liferay get back the Encoded parameter, the "%25" is set into "%" but no Wicket Code transform back the "%3A" to ":" Note : Wicket Encoding is done by : org.apache.wicket.request.target.coding.WebRequestEncoder : line 86     escapedValue = URLEncoder.encode(escapedValue, application.getRequestCycleSettings().getResponseRequestEncoding()); and I can't find a decode for this level in Wicket's code. The parameter received is like "%3Aorg.apache.wicket.examples.navomatic.Page2". So I add a call to decode function from "org.apache.wicket.protocol.http.RequestUtils" Here is my code modification (it's maybe possible to find a another solution too) in the class "org.apache.wicket.protocol.http.request.WebRequestCodingStrategy", method addBookmarkablePageParameters(final Request request, final RequestParameters parameters) (line : 521 / SVN revision : 585043) I change from             final String[] components = Strings.split(requestString, Component.PATH_SEPARATOR); to             final String[] components = Strings.split(RequestUtils.decode(requestString),Component.PATH_SEPARATOR); (Note: I test it with jetspeed and it works) The main remaining problem is about Ajax portlet. I have this Error : ======================================= 15:38:53,248 ERROR [[default]:731] "Servlet.service()" pour la servlet default a lancé une exception java.lang.NullPointerException     at org.apache.wicket.protocol.http.WebResponse.redirect(WebResponse.java:204)     at org.apache.wicket.protocol.http.BufferedWebResponse.close(BufferedWebResponse.java:66) Seems like a strange NPE to me. Looking at WebResponse.java:204, the only null reference in that code line could be the url string itself, but as the stacktrace indicates, the redirect is called from BufferedWebResponse.java:66 and there it only does that *if* the url != null. Can you further debug this? Your Right, the redirectURL is not null in BufferedWebResponse.java:66, but is set to null by Liferay's code on : com.liferay.portlet.PortletServletResponse code is :     public String encodeRedirectURL(String url) {         return null;     } I don't know why, but I have to see with Liferay's Team. (very strange code) Ate --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Charles CHAHBAZIAN [EMAIL PROTECTED] Directeur Recherche & Développement 15 quai Tilsitt - 69002 LYON tel. +33 478 38 54 18 - fax +33 426 68 91 68 ............................................................................... >>> www.alinto.net - The messaging reflex <<< --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]