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 : --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]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, AteThijs--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] |
- Portlet howto Thijs
- Re: Portlet howto Ate Douma
- Re: Portlet howto Thijs
- Re: Portlet howto Charly
- Re: Portlet howto Ate Douma
- Re: Portlet howto Patrick Gill
- Re: Portlet howto Ate Douma
- Re: Portlet howto Patrick Gill
- Re: Portlet howto Charly
- Re: Portlet howto Ate Douma
- Re: Portlet howto Charles CHAHBAZIAN
- Re: Portlet howto Thijs
- Re: Portlet howto Thijs
- Re: Portlet howto Miso