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