I don't know the Sun Portal that well, but AFAIK they have (or are working on) beta Portlet API 2.0 (JSR-286) support
already.
As the interfaces which Wicket Portlet currently needs from Apache Portals Bridges Common are natively supported with
JSR-286, the easiest solution is:
a) waiting for JSR-286 to finally get published (it is already accepted, just
still not made available publicly :( )
b) upgrade Wicket portlet support to (optionally, if JSR-286 is available at runtime) make use of the JSR-286 API's
instead of the custom Bridges interfaces
For b) I hope to get started on that ASAP. As I'm also working on a big upgrade/refactoring of both Pluto 2.0 and
Jetspeed 2.2 to get them aligned, this is something I'll have to try to squeeze in sometime soon.
*Any help with this is very much appreciated.*
For a) I just hope the JCP will speed up their administrative handling of it.
But, we don't have to wait for the public release of JSR-286 to start working on it. Pluto 2.0 (trunk development) as
well as other portals do have (beta) JSR-286 support which can be used for developing and testing already.
We only don't have a formal portlet-api-2.0.jar available from any public repository, which is somewhat painful as
adding it as dependency on Wicket would break out-of-the-box building for everyone who hasn't installed that jar
locally. That's the main reason (and lack of time of course) I haven't started on this already.
Now, if you're stuck on a Portal which doesn't provide JSR-286 support any time soon, and neither provides
implementations of those Bridges interfaces, you'll have to write them yourself I'm afraid.
As the experience of Thijs Vonk with Liferay showed, it really depends on how "open" and flexible the core features of
that portal engine is, and whether they already have similar (albeit still proprietary) support of these features.
But if/once they do have preliminary (as Jetspeed right now) or real JSR-286 support, providing implementations for
these interfaces should not be difficult.
Regards,
Ate
Wilhelmsen Tor Iver wrote:
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]
