You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Thijs <cr...@mytweakers.net> on 2007/10/08 11:53:30 UTC
Portlet howto
Hi (Ate?)
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'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).
Thijs
--
View this message in context: http://www.nabble.com/Portlet-howto-tf4587073.html#a13093514
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Portlet howto
Posted by Ate Douma <at...@douma.nu>.
Gwyn Evans wrote:
> On Monday, October 8, 2007, 11:45:39 AM, Ate <at...@douma.nu> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Portlet howto
Posted by Gwyn Evans <gw...@gmail.com>.
On Monday, October 8, 2007, 11:45:39 AM, Ate <at...@douma.nu> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Portlet howto
Posted by Thijs <cr...@mytweakers.net>.
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=AjaxApplication&p_p_action=1&p_p_col_id=column-1&p_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_wicketexamples&p_p_action=1&p_p_state=normal&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_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: users-unsubscribe@wicket.apache.org
>>
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>>
>> --
>> Charles CHAHBAZIAN cchahbazian@alinto.net
>> 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: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Portlet-howto-tf4587073.html#a13467811
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Portlet howto
Posted by Thijs <cr...@mytweakers.net>.
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_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: users-unsubscribe@wicket.apache.org
>
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
>
> --
> Charles CHAHBAZIAN cchahbazian@alinto.net
> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Portlet-howto-tf4587073.html#a13427052
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Portlet howto
Posted by Ate Douma <at...@douma.nu>.
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Portlet howto
Posted by Miso <mi...@gmail.com>.
Hello
I tried your solution on Liferay 4.3.3 and it seams to work.
Michal
--
View this message in context: http://www.nabble.com/Portlet-howto-tf4587073.html#a13330812
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Portlet howto
Posted by Patrick Gill <pa...@multicom.co.uk>.
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Portlet howto
Posted by Ate Douma <at...@douma.nu>.
Patrick Gill wrote:
> 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-r543172----portals-jetspeed-2-trunk-commons-src-java-org-apache-jetspeed-portlet-PortletResourceURLFactoryImpl.java-tf3847355.html#a10896778
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();
}
}
>
> 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...
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.
> 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.
>
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?).
Good luck
Ate
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Portlet howto
Posted by Patrick Gill <pa...@multicom.co.uk>.
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-r543172----portals-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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Portlet howto
Posted by Ate Douma <at...@douma.nu>.
Hi Charly,
Great to hear you're working on the Liferay support!
I do have some questions about your interface implementations:
- is the LiferayToPortalBridgeServletContextProvider the same as already provided by Liferay (for the Struts Bridge support)?
- 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).
Regards,
Ate
Charly wrote:
> 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 = renderResponse.createRenderURL();
> 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
>>>> 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-name>AjaxApplication</filter-name>
>>> <url-pattern>/ajax/*</url-pattern>
>>> <dispatcher>REQUEST</dispatcher>
>>> <dispatcher>INCLUDE</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>
>>> <description>Examples using wicket's built-in AJAX.</description>
>>> <portlet-name>AjaxApplication</portlet-name>
>>> <display-name>ajax</display-name>
>>>
>>> <portlet-class>org.apache.wicket.protocol.http.portlet.WicketPortlet</portlet-class>
>>> <init-param>
>>> <name>wicketFilterPath</name>
>>> <value>/ajax</value>
>>> </init-param>
>>> <supports>
>>> <mime-type>*/*</mime-type>
>>> <portlet-mode>VIEW</portlet-mode>
>>> </supports>
>>> <portlet-info>
>>> <title>Wicket Ajax Example</title>
>>> <keywords>Wicket</keywords>
>>> </portlet-info>
>>> </portlet>
>>>
>>> As you will notice of the example above, I also defined support for all
>>> possible mime-types (<mime-type>*/*</mime-type>), to support ResourceURLs
>>> setting any
>>> mime-type they might need. This is just to ensure the portal/container
>>> isn't going to complain if your ResourceURL handling is going to set an
>>> unexpected
>>> mime-type. If you happen to know all possible mime-types before hand you
>>> also can enumerate each of them, instead of simply allowing everything.
>>>
>>> That should be all you need to do to get started.
>>> Please let me know if you encounter any problems and also if you get
>>> working just fine of course :)
>>>
>>> HTH,
>>>
>>> Ate
>>>
>>>
>>>> Thijs
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>>
>>
>>
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: users-unsubscribe@wicket.apache.org For additional
> commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Portlet howto
Posted by Thijs <cr...@mytweakers.net>.
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
>> 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-name>AjaxApplication</filter-name>
> <url-pattern>/ajax/*</url-pattern>
> <dispatcher>REQUEST</dispatcher>
> <dispatcher>INCLUDE</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>
> <description>Examples using wicket's built-in AJAX.</description>
> <portlet-name>AjaxApplication</portlet-name>
> <display-name>ajax</display-name>
>
> <portlet-class>org.apache.wicket.protocol.http.portlet.WicketPortlet</portlet-class>
> <init-param>
> <name>wicketFilterPath</name>
> <value>/ajax</value>
> </init-param>
> <supports>
> <mime-type>*/*</mime-type>
> <portlet-mode>VIEW</portlet-mode>
> </supports>
> <portlet-info>
> <title>Wicket Ajax Example</title>
> <keywords>Wicket</keywords>
> </portlet-info>
> </portlet>
>
> As you will notice of the example above, I also defined support for all
> possible mime-types (<mime-type>*/*</mime-type>), to support ResourceURLs
> setting any
> mime-type they might need. This is just to ensure the portal/container
> isn't going to complain if your ResourceURL handling is going to set an
> unexpected
> mime-type. If you happen to know all possible mime-types before hand you
> also can enumerate each of them, instead of simply allowing everything.
>
> That should be all you need to do to get started.
> Please let me know if you encounter any problems and also if you get
> working just fine of course :)
>
> HTH,
>
> Ate
>
>>
>> Thijs
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Portlet-howto-tf4587073.html#a13094499
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Portlet howto
Posted by Ate Douma <at...@douma.nu>.
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-name>AjaxApplication</filter-name>
<url-pattern>/ajax/*</url-pattern>
<dispatcher>REQUEST</dispatcher>
<dispatcher>INCLUDE</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>
<description>Examples using wicket's built-in AJAX.</description>
<portlet-name>AjaxApplication</portlet-name>
<display-name>ajax</display-name>
<portlet-class>org.apache.wicket.protocol.http.portlet.WicketPortlet</portlet-class>
<init-param>
<name>wicketFilterPath</name>
<value>/ajax</value>
</init-param>
<supports>
<mime-type>*/*</mime-type>
<portlet-mode>VIEW</portlet-mode>
</supports>
<portlet-info>
<title>Wicket Ajax Example</title>
<keywords>Wicket</keywords>
</portlet-info>
</portlet>
As you will notice of the example above, I also defined support for all possible mime-types (<mime-type>*/*</mime-type>), to support ResourceURLs setting any
mime-type they might need. This is just to ensure the portal/container isn't going to complain if your ResourceURL handling is going to set an unexpected
mime-type. If you happen to know all possible mime-types before hand you also can enumerate each of them, instead of simply allowing everything.
That should be all you need to do to get started.
Please let me know if you encounter any problems and also if you get working just fine of course :)
HTH,
Ate
>
> Thijs
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org