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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
