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...
First of all, you need to make sure the portal (e.g. Liferay ) provides an implementation of the Apache Portals Bridges
PortletResourceURLFactory interface, see:
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 is 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-168 container as well, as long as a portal provides a proprietary 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:
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
The one I provide with Jetspeed 2 (out-of-the-box through a shared library) contains the following:
Another way of defining these (maybe easier for testing) is providing them as portlet init parameters (named
"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.
You will also need to modify the wicket filter mapping in your
web.xml to support handling both direct requests as well include dispatch requests, e.g.
Note: this requires at least a Servlet 2.4 descriptor just as in the wicket-examples application.
Enabling portlet support
By default portlet support will *not* be enabled (as of wicket 1.3.0-beta5), because even when deployed in a portlet supporting web container, a Wicket application might not or should not be used as portlet.
So, you'll have to provide a configuration setting to let WicketFilter detect if it actually is running in a Portlet Context.
This can be done using a boolean (true|false) value on three different levels: as filter parameter, web.xml context parameter, or finally as property in the above described WicketPortlet.properties.
WicketFilter will check for such a configuration in the above order.
To define this on filter level (possibly overriding a setting on web.xml or WicketPortlet.properties level):
To define this on web.xml context level as default for the whole of the web application (possibly overriding a setting on WicketPortlet.properties level):
Finally, you can also set this globally through the classpath in WicketPortlet.properties:
Note: Jetspeed-2 provides the above default/global setting out of the box, so you won't need to configure this for your web application when deploying on Jetspeed-2.
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
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.
Note: the wicket filter path must be also specified with the
"filterMappingUrlPattern" parameter in web.xml (this time with the trailing
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
We were not able to run under Jetspeed without adding the following configurations to the web.xml
You don't need to add the above changes manually in your web.xml: Jetspeed can do that automatically for you if you "drop" your war file in the "hot" WEB-INF/deploy folder of the portal application.
For more information, check out: http://portals.apache.org/jetspeed-2/multiproject/jetspeed-deploy-tools/index.html, first paragraph, Deploying Portlets in Jetspeed-2: An End User View, explains it all.