I'll be on training for the rest of the week, but if I find time in between
I'll make sure to have a look. Otherwise next weekend :)

Thijs 

Ate Douma wrote:
> 
> 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]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Portlet-howto-tf4587073.html#a13094499
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to