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]
