Re: Portlet howto

[Thijs]

I've tried to localize this.
It looks like the generated url s not correct. 
this is the source for the ajax link example 
href=# onclick=var
wcall=wicketAjaxGet('http://localhost:8080/web/guest/admin?p_p_id=AjaxApplicationp_p_action=1p_p_col_id=column-1p_p_col_count=1;',null,null,
function() {return Wicket.$$(this)}.bind(this));return !wcall; ...


notice the 'p_p_id=AjaxApplication' while this should be:
'p_p_id=AjaxApplication_WAR_wicketexamples'

I'm trying to find where the this javascript fragment URL is generated in
wicket because the normal, non ajax links do point to the correct location:

href=http://localhost:8080/web/guest/admin?p_p_id=AjaxApplication_WAR_wicketexamplesamp;p_p_action=1amp;p_p_state=normalamp;p_p_mode=view.
 

Can someone point me in the right direction?

Thijs


Thijs wrote:
 
 Hello Charly,
 
 Have you got any answer from Liferay jet?
 We could put this in an issue in the Liferay support system. Or post a
 message on the forum.
 
 I tried something very ugly I implemented encodeRedirectURL as encodeURL
 is implemented. (copied the code)  This prevents the nullpointer of
 showing up. But then I get this message:
 
 13:08:40,375 WARN  [PortletLocalServiceImpl:138] Portlet not found for 1
 AjaxApplication
 
 Which probably is logical :)
 I'll try and dig some further.
 
 Thijs
 
 
 
 
 
 Charles CHAHBAZIAN wrote:
 
 
 
 
   
   
 
 
 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_wicketexamplesamp;p_p_action=0amp;p_p_state=normalamp;p_p_mode=viewamp;p_p_col_id=column-1amp;p_p_col_count=1amp;_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 

Re: Portlet howto

[Thijs]

Hello Charly,

Have you got any answer from Liferay jet?
We could put this in an issue in the Liferay support system. Or post a
message on the forum.

I tried something very ugly I implemented encodeRedirectURL as encodeURL is
implemented. (copied the code)  This prevents the nullpointer of showing up.
But then I get this message:

13:08:40,375 WARN  [PortletLocalServiceImpl:138] Portlet not found for 1
AjaxApplication

Which probably is logical :)
I'll try and dig some further.

Thijs





Charles CHAHBAZIAN wrote:
 
 
 
 
   
   
 
 
 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_wicketexamplesamp;p_p_action=0amp;p_p_state=normalamp;p_p_mode=viewamp;p_p_col_id=column-1amp;p_p_col_count=1amp;_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
 

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_wicketexamplesp_p_action=0p_p_state=normalp_p_mode=viewp_p_col_id=column-1p_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 

Re: Portlet howto

[Ate Douma]

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.

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'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.

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?

Ate


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Portlet howto

[Charly]

Hello,
I have the beginning of a solution !
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.
I translate also the "_wu" (WicketPortlet.WICKET_URL_PORTLET_PARAMETER)
parameter into differents parameters

You can have a look to my 3 classes at the end of this mail.

I've got a problem for all bookmarkablePage, because the argument are
encoded by Wicket, and Liferay encode it second time. 
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)
 at
org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:336)
 at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:175)
 at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
 at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
 at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:691)
 at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:594)
 at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505)
 at
com.liferay.portlet.PortletRequestDispatcherImpl.include(PortletRequestDispatcherImpl.java:245)
 at
com.liferay.portlet.PortletRequestDispatcherImpl.include(PortletRequestDispatcherImpl.java:87)
 at
org.apache.wicket.protocol.http.portlet.WicketPortlet.processRequest(WicketPortlet.java:519)
 at
org.apache.wicket.protocol.http.portlet.WicketPortlet.doView(WicketPortlet.java:416)
 at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:235)
()
===

How can I go forward ? any suggestion ?




===
Here is my 3 implementation classes :
===
package com.liferay.portlet;

import java.util.Map;

import javax.portlet.PortletConfig;
import javax.portlet.PortletException;
import javax.portlet.RenderRequest;
import javax.portlet.RenderResponse;

import org.apache.portals.bridges.common.PortletResourceURLFactory;

public class LiferayToPortalBridgePortletResourceURLFactory implements
PortletResourceURLFactory
{
 public static final String WICKET_PREFIX =
"org.apache.wicket_";

 public String createResourceURL( PortletConfig portletConfig,
RenderRequest renderRequest, RenderResponse renderResponse, Map
portletArg ) throws PortletException
 {
  String retval = "";

  final long plid = ( (RenderResponseImpl)renderResponse
).getPlid();
  final PortletURLImpl portletUrl = new PortletURLImpl(
(RenderRequestImpl)renderRequest, portletConfig.getPortletName(), plid,
true );
  retval = portletUrl.toString();
  return retval;
 }

}
===
package com.liferay.portlet;

import java.io.IOException;
import java.util.Iterator;
import java.util.Map;

import javax.portlet.GenericPortlet;
import javax.portlet.PortletRequest;
import javax.portlet.PortletResponse;
import javax.servlet.ServletContext;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import org.apache.portals.bridges.common.ServletContextProvider;
import org.apache.wicket.protocol.http.portlet.WicketPortlet;

import com.liferay.portal.kernel.servlet.HttpHeaders;
import com.liferay.portal.kernel.util.ContentTypes;
import com.liferay.portlet.ActionRequestImpl;
import com.liferay.portlet.ActionResponseImpl;
import com.liferay.portlet.PortletContextImpl;
import com.liferay.portlet.RenderRequestImpl;
import com.liferay.portlet.RenderResponseImpl;
import 

Re: Portlet howto

[Patrick Gill]

Hi Ate and Charly,

I'm working on the same thing. I'm currently using Liferay's implementation
for ServletContextProvider
(com.liferay.util.bridges.struts.LiferayServletContextProviderWrapper) .


Ate Douma wrote:
 
 - in the LiferayToPortalBridgePortletResourceURLFactory you seem to simply
 generate a Portlet RenderURL for the ResourceURL.
How can that ever work? I would assume Liferay is going to render a
 full page for such a request and not just the output of
the targetted portlet (with full control over its response).
 

Sorry, that is probably my fault. I was trying to create an implementation
of PortletResourceURLFactory for Liferay since there isn't one currently. I
based it on the svn commit I found on here:

http://www.nabble.com/svn-commit%3A-r543172portals-jetspeed-2-trunk-commons-src-java-org-apache-jetspeed-portlet-PortletResourceURLFactoryImpl.java-tf3847355.html#a10896778

But I'm not sure about how Liferay has done its implementation, so it's been
severely reduced. I couldn't see any methods for creating a ResourceURL...
Anyway, I've opened an issue regarding implementation at:

http://support.liferay.com/browse/LEP-3873

No reply so far, unfortunately. I've also asked for some help on the Liferay
forums:

http://www.liferay.com/web/guest/community/forums/message_boards/message/169952

But again, no reply. At the moment this is the main issue holding me back.

-- 
View this message in context: 
http://www.nabble.com/Portlet-howto-tf4587073.html#a13111385
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Portlet howto

[Patrick Gill]

Ate Douma wrote:
 
 That was my initial attempt at it.
 For Jetspeed, I have much improved/simplyfied this after I added
 ResourceURL handling natively to the portal (internally), and I only need
 to set a predefined 
 flag/parameter to tell it to use it (instead of creating a plain RenderURL
 which simply won't do):
 
public class PortletResourceURLFactoryImpl implements
 PortletResourceURLFactory
{
/*
 * (non-Javadoc)
 *
 * @see
 org.apache.portals.bridges.common.PortletResourceURLFactory#createResourceURL(javax.portlet.PortletConfig,
 *  javax.portlet.RenderRequest, javax.portlet.RenderResponse,
 *  java.util.Map)
 */
public String createResourceURL(PortletConfig config, RenderRequest
 request, RenderResponse response, Map parameters)
throws PortletException
{
PortletURL url = response.createRenderURL();
if (parameters != null)
{
url.setParameters(parameters);
}
   
 url.setParameter(PortalReservedParameters.PORTLET_RESOURCE_URL_REQUEST_PARAMETER,
 );
return url.toString();
}
}
 

Yes, I saw this implementation and tried looking for a parameter like this
in Liferay, but couldn't find any.


Ate Douma wrote:
 
 Well, you'll have to check the Liferay portal/container internals for it
 as it must be told not to create a plain RenderURL (as your current
 implementation 
 does) but instead switch to this pre-JSR-286 ResourceURL handling. How to
 do that (if it is already supported) I can't tell you as I don't know
 anything about 
 Liferay's internals.
 
 Well, yes. Without the ResourceURL support you're out of luck I'm afraid.
 I suggest just keep pinging the Liferay devs (maybe they use IRC?).
 

Indeed. The issue has been open for almost 2 weeks now and there's been no
reply. I will try updating it with what you mention here, see if that
simplifies it for them, but I don't want to be a pain since Liferay is free
and open source... If only they pointed me in the right direction I'm sure I
could do something with it. It's cold and lonely out here! :D

Patrick
-- 
View this message in context: 
http://www.nabble.com/Portlet-howto-tf4587073.html#a13113086
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Portlet howto

[Ate Douma]

Thijs wrote:

Hi (Ate?)

Hi Thijs,



Is there someone who could write a small wikipage on what I have to change
in a Quickstart project to deploy it as a portlet?

I can and will, and even promised to do so last week :(
But I'm currently crammed with two new client (portal) projects put on my table last week as well as adding some finer integration for Wicket Header 
Contributions in Jetspeed before we release Jetspeed 2.1.3 hopefully somewhere next week (you can expect a few small. but transparent, changes to the Wicket 
Portlet support shortly).



I'm trying to get the examples.war working on a liferay portal
(liferay.com). But this is giving me so much trouble that I just want to
work with an 'empty' quickstart. 
Because I'm not sure if it is Wicket that is giving me the headache's or

Liferay (with their custom xml configs).

:)

To get you started, I'll give the important configuration (and portal runtime) 
settings/requirements inline here.
These will eventually end up on a Wiki page, but I'm afraid I won't have time 
to write that before next week.

First of all, you need to make sure the portal (Liferay in your case) provides an implementation of the Apache Portals Bridges PortletResourceURLFactory 
interface, see:

  
http://portals.apache.org/bridges/multiproject/portals-bridges-common/xref/org/apache/portals/bridges/common/PortletResourceURLFactory.html

The related jar containing this interface, portal-bridges-common-1.0.3.jar (available from repo1.maven.org) needs to be in your portlet classpath directly or 
provided in the shared classpath of your portal.


You will have to check if your portal (Liferay) provides support for these kind of RenderURLs which allows direct access to a portlet and full control over its 
response (like setting content type etc.). A ResourceURL will be a standard JSR-286 (Portlet API 2.0) feature but as it isn't yet released (it will be soon) for 
which I created this temporary interface to allow using it in a JSR-186 container as well, as long as a portal provides a propetairy mapping for it.
Jetspeed 2 does, and AFAIK, most other portals do as well, you just need to find out how to map this for Liferay and provide (or use) their proprietary api to 
handle it.


Secondly, you need also to provide an implementation of the Apache Portals 
Bridges ServletContextProvider interface, see:
  
http://portals.apache.org/bridges/multiproject/portals-bridges-common/xref/org/apache/portals/bridges/common/ServletContextProvider.html

That I know Liferay already provides as I know it provides support for the 
Apache Portals Struts Bridge which uses the same interface.
Note: this interface also is provided with the portal-bridges-common-1.0.3.jar 
(and earlier).
BTW: this inteface also won't be needed anymore for proper JSR-286 containers. Once they are available I'll upgrade the Wicket Portlet support to really work 
out-of-the-box and portal specific configurations won't be needed then.


The implementations of these two interfaces need to be provided to the 
WicketPortlet.
There are three ways of doing that, the simplest is providing a WicketPortlet.properties file in the classpath under package 
org.apache.wicket.protocol.http.portlet.


The one I provide with Jetspeed 2 (out-of-the-box through a shared library) 
contains the following:

  # Default Jetspeed-2 provided WicketPortlet ServletContextProvider and 
PortletResourceURLFactory
  
org.apache.portals.bridges.common.ServletContextProvider=org.apache.jetspeed.portlet.ServletContextProviderImpl
  
org.apache.portals.bridges.common.PortletResourceURLFactory=org.apache.jetspeed.portlet.PortletResourceURLFactoryImpl

Another way of defining these (maybe easier for testing) is providing them as portlet init parameters (named ServletContextProvider and 
PortletResourceURLFactory) or even as web.xml context param using their full class name just as in the properties file.


Defining these through WicketPortlet.properties though will allow you to keep 
this portal specific configuration out of your application and thus be more 
portable.

Additionally, you will need to modify the wicket filter mapping in your web.xml 
to support handling both direct requests as well include dispatch requests, e.g.

  filter-mapping
filter-nameAjaxApplication/filter-name
url-pattern/ajax/*/url-pattern
dispatcherREQUEST/dispatcher
dispatcherINCLUDE/dispatcher
  /filter-mapping

Note: this requires at least a Servlet 2.4 descriptor just as in the 
wicket-examples application.

Finally, in your portlet.xml, you need to define a portlet init-param named wicketFilterPath with as value the url-pattern of your wicket application, but 
without the trailing /*, e.g.:


  portlet
descriptionExamples using wicket's built-in AJAX./description
portlet-nameAjaxApplication/portlet-name
display-nameajax/display-name

portlet-classorg.apache.wicket.protocol.http.portlet.WicketPortlet/portlet-class
init-param
  

Re: Portlet howto

[Charly]

Hi Ate and Thijs,
I'm actually trying to get Wicket working with Liferay portal 4.3.2. I
already implement the 2 interfaces (not really sure of my work) and I
can actually see the portlet example content of Wicket in Liferay.

Here the steps I've done :
- use Liferay 4.3.2 with tomcat (there's aparently a problem with Jetty)
- Start Tomcat
- upload wicket-exemples.war from plugin porltlet in liferay
- Stop Tomcat
- add a new file called WicketPortlet.properties in the
TC_HOME/webapp/wicket-exemples/WEB-INF/classes/org/apache/wicket/protocol/http/portlet
directory with content :
 org.apache.portals.bridges.common.ServletContextProvider=com.liferay.portal.apache.bridges.struts.LiferayToPortalBridgeServletContextProvider

org.apache.portals.bridges.common.PortletResourceURLFactory=com.liferay.portlet.LiferayToPortalBridgePortletResourceURLFactory
- Change in the portlet.xml the content type for all portlets from
"*/*"
to text/html (Liferay doesn't render generic content type !)

After that, I must merge the differents classpath because Wicket must
have access to Liferay's class with my implentation classes... (maybe
we can do it better)
- Move the TC_HOME/webapp/ROOT/WEB-INF/lib content to a new
folder TC_HOME/common/lib/ext_liferay
- Move the TC_HOME/webapp/wicket-exemples/WEB-INF/lib content
to a new folder TC_HOME/common/lib/ext_wicket
- Change the class path in the TC_HOME/conf/catalina.properties
by adding ${catalina.home}/common/lib/ext_liferay/*.jar to the
common.loader property
common.loader=${catalina.home}/common/classes,${catalina.home}/common/i18n/*.jar,${catalina.home}/common/endorsed/*.jar,${catalina.home}/common/lib/*.jar,${catalina.home}/common/lib/ext/*.jar,${catalina.home}/common/lib/ext_liferay/*.jar,${catalina.home}/common/lib/ext_wicket/*.jar
- Add this 2 jars to TC_HOME/common/lib/ext_liferay
- liferaytoapacheportalbridge.jar (my implentation of the 2 interfaces
from PortalBridge)
- portals-bridges-common-1.0.3.jar
- To prevent version conflit of Spring, remove
TC_HOME/common/lib/ext_liferay/spring.jar (Spring v1) jar file
- the Spring v2 jar file from Wicket will be used.

- Start Tomcat

At this point, you can see the Wicket Example portlet or HelloWorld
portlet in Liferay, but none of the url links works...

Here is my code for :
com.liferay.portlet.LiferayToPortalBridgePortletResourceURLFactory
---
public class LiferayToPortalBridgePortletResourceURLFactory implements
PortletResourceURLFactory
{

 public String createResourceURL( PortletConfig portletConfig,
RenderRequest renderRequest, RenderResponse renderResponse, Map
portletArg ) throws PortletException
 {
  String retval = "";

  final PortletURL url = "">
  if ( portletArg != null )
  {
   url.setParameters( portletArg );
  }
  retval = url.toString();
  return retval;
 }
}


--

And here is my implementation of
com.liferay.portal.apache.bridges.struts.LiferayToPortalBridgeServletContextProvider
:

// I get inspired from Liferay Struts bridge :
com.liferay.portal.apache.bridges.struts.LiferayServletContextProvider

public class LiferayToPortalBridgeServletContextProvider implements
ServletContextProvider
{
 public ServletContext getServletContext( GenericPortlet portlet )
 {
  final PortletContextImpl portletCtxImpl =
(PortletContextImpl)portlet.getPortletContext();

  return this.getServletContext(
portletCtxImpl.getServletContext() );
 }

 public HttpServletRequest getHttpServletRequest( GenericPortlet
portlet, PortletRequest req )
 {
  HttpServletRequest httpReq = null;

  if ( req instanceof ActionRequestImpl )
  {
   httpReq = ( (ActionRequestImpl)req
).getHttpServletRequest();

   final String contentType = httpReq.getHeader(
HttpHeaders.CONTENT_TYPE );

   if ( contentType != null  contentType.startsWith(
ContentTypes.MULTIPART_FORM_DATA ) )
   {

try
{
 httpReq = new UploadServletRequest( httpReq );
}
catch( final IOException ioe )
{}

httpReq = new LiferayStrutsRequestImpl( httpReq );
   }
   else
   {
httpReq = new LiferayStrutsRequestImpl(
(ActionRequestImpl)req );
   }
  }
  else
  {
   httpReq = new LiferayStrutsRequestImpl(
(RenderRequestImpl)req );
  }

  return httpReq;
 }

 public HttpServletResponse getHttpServletResponse( GenericPortlet
portlet, PortletResponse res )
 {
  if ( res instanceof RenderResponseImpl )
   return ( (RenderResponseImpl)res ).getHttpServletResponse();
  else return ( (ActionResponseImpl)res
).getHttpServletResponse();
 }

 public ServletContext getServletContext( ServletContext ctx )
 {
  return new LiferayServletContext( ctx );
 }

}

Charles

Thijs a crit:

  I'll be on training for the rest of the week, but if I find time in between
I'll make sure to have a look. Otherwise next weekend :)

Thijs 

Ate Douma wrote:
  
  
Thijs wrote:


  Hi (Ate?)
  

Hi Thijs,



  Is there someone who could write a small wikipage on what I have to

Re: Portlet howto

[Gwyn Evans]

On Monday, October 8, 2007, 11:45:39 AM, Ate [EMAIL PROTECTED] wrote:

 To get you started, I'll give the important configuration (and
 portal runtime) settings/requirements inline here.
 These will eventually end up on a Wiki page, but I'm afraid I won't
 have time to write that before next week.

http://cwiki.apache.org/WICKET/portal-howto.html :-)

/Gwyn


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Portlet howto

[Ate Douma]

Gwyn Evans wrote:

On Monday, October 8, 2007, 11:45:39 AM, Ate [EMAIL PROTECTED] wrote:


To get you started, I'll give the important configuration (and
portal runtime) settings/requirements inline here.
These will eventually end up on a Wiki page, but I'm afraid I won't
have time to write that before next week.


http://cwiki.apache.org/WICKET/portal-howto.html :-)

Nice ;)

Thanks Gwyn



/Gwyn


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]