Liferay is not really supported, We have it running but have hacked
wicket to do so (in a combindation of a bridges implementation and a
custom wicket version). Especially to get the Ajax stuff working correctly.
We are hoping that with portlet 2.0 supported both by Liferay and wicket
that the issues are going to be a lot less. Especially with
resourceUrl's and HTTP header's / cookies
Thijs
Wilhelmsen Tor Iver schreef:
We have (wisely :) ) chosen Wicket as web framework, but also chosen Sun
Portal as the portal engine (not just Pluto but the commercial product).
This causes a problem since Sun apparently haven't implemented the two
interfaces required by Apache's bridge, so Wicket 1.3.x portlets do not
work since the WicketPortlet appears to require the bridge.
Are there anyone else who have used this combination successfully?
As I see it, there are four possible solutions:
1) Provide implementations of the interfaces that hook into the Sun
portlet engine
2) Make a custom WicketPortlet that does away with the bridge
requirement and does all translation between the portlet world and the
Wicket world. Has the disadvantage of effectively redoing work that the
bridge already does
3) Make a custom Wicket "Channel" in the portlet server to (in effect)
provide such a bridge (or wait for someone at Sun to write one :) )
which has the disadvantage of being tied to Sun's product
4) Serve the Wicket portlets from a second portlet container that _does_
support the bridge (Liferay, Jetspeed or JBoss if I am not mistaken),
and use WSRP to show them in Sun's portal
Which do you guys think is most likely to succeed?
Med vennlig hilsen
TOR IVER WILHELMSEN
Senior systemutvikler
Arrive AS
T (+47) 48 16 06 18
E-post: [EMAIL PROTECTED]
http://servicedesk.arrive.no
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
