You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Bookmarkable link

Table of contents

To get you started, I'll give the important configuration (and portal runtime) settings/requirements inline here.
These will eventually end up tidied up, but for the moment, this is it...

PortletResourceURLFactory

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

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 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 (Oct'07 - 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.

ServletContextProvider

Secondly, you need also to provide an implementation of the Apache Portals Bridges ServletContextProvider interface, see:
ServletContextProvider

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.

Wicket

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.

Portlet.xml

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 us know if you encounter any problems and also if you get working just fine of course (smile)

  • No labels