Re: Wicket portles in Sun Portal
Got it to work after building portlet-bridges-common from the trunk
source.
- The change I made to PortletWindowUtils which seems to work (so far
*crosses fingers*):
public static String getPortletWindowId(PortletSession session)
{
final Object tmp = session.getAttribute(PORTLET_WINDOW_ID);
String portletWindowId = null;
if (tmp != null) {
portletWindowId = tmp.toString();
}
if ( portletWindowId == null )
{
synchronized (session)
{
String value = String.valueOf(Math.random());
session.setAttribute(PORTLET_WINDOW_ID, value);
- Some of the Maven 2 dependencies for the bridge projects were...
absent. Mostly due to deprecated/old groupIds (non-hierarchical like
castor/castor instead of the hierarchical ids). Worked around it by
building/installing portlet-bridges-common explicitly then adding an
exclusion of the parent project to the dependency in my POM so that I
wasn't dependent on e.g. the perl bridge failing to build because of
these rotten dependencies.
- I was surpried the trunk source's POMs did not use 1.0-SNAPSHOT or the
like for version now, if 1.0.4 is actually released. Don't the
portlet-bridge developers use Maven 2 and thus do not release using mvn
which would have updated the version numbers in the pom.xml files?
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]
SV: Wicket portles in Sun Portal
Thijs Vonk wrote: > Ate Douma wrote: Thanks to both of you! > Note though that you have to build a svn copy of the > portlet-container. > RC2 contains a bug I found which prevents Ajax to work correctly. Will try that. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket portles in Sun Portal
Ate Douma wrote: Wilhelmsen Tor Iver wrote: To dig up this old thread: I now use Ate Douma's patch for JSR-286 support from https://issues.apache.org/jira/browse/WICKET-1620 which has removed the need for the portal to implement the Apache portlet bridge's two interfaces. A small step for man etc. :) Well, credits for those patches go to Thijs Vonk, I'm just the assignee of that issue :) Note though: those patches *as such* still need quite some refactoring (as already discussed on this list before) and the final JSR-286 support very likely will turn out a little bit different... For those who haven't discovered this yet, I might have a nice news update: JSR-286 has finally landed! See: http://jcp.org/aboutJava/communityprocess/final/jsr286/index.html Finally :) There now is an issue - the same I had in JBoss - that it seems the bridge has a bug where the WicketFilterPortletContext call to ServletPortletSessionProxy.createProxy(filterRequestContext.getRequest() ) places a Double into the window-id propery that later will be cast to String... No. This is *not* a bug in the bridge, but one in their portlet container implementation. The method concerning this issue is o.a.p.bridges.util.PortletWindowUtils.getPortletWindowId(PortletSession) That method (which I wrote) is 100% following the JSR-168 specification, its just too bad JBoss Portal (and now it seems also Sun Portal) fail to follow those rules concerning this functionality. ... makes me wonder if they (now) share some common codebase ? ... Anyway, I know this is annoying and I could maybe "fix" this through a workaround (not sure yet though: this exception might indicate something more/worse is wrong, but I haven't debugged *their* engines yet). But... such a fix or workaround will take some time to formally "land" in a new release of bridges anyway, and maybe by that time this is moot if we have (basic) JSR-286 support in place for Wicket by then ... I tested on Sun Portlet container and ran into this problem as well. The 'QuickFix' I used was to alter the Bridges code and check if it was a String or not and depending I cast to String or to Double and then to String. I know it's dirty (as I didn't check if it actually is a worse problem as Ate indicated), but after I fixed that I haven't run into any other problems with it yet. Note though that you have to build a svn copy of the portlet-container. RC2 contains a bug I found which prevents Ajax to work correctly. Are there plans to completely disconnect the Wicket portlet impl. from the bridge (i.e. including this dependency to ServletPortletSessionProxy)? Yes/no. JSR-286 support will no longer need/depend on the two ServletContextProvider and PortletResourceURLFactory implementations. Additionally, the ServletPortletSessionProxy functionality *might* be replaced by a native JSR-286 feature but... that is an optional feature of the spec, so it depends if the underlying portlet container does support it or not. If not, the ServletPortletSessionProxy (which provides exactly the same functionality as this optional feature... wonder how come?) will still be needed. But in that case, the part you encountered the exception in comes from determining the Portlet WindowId, and *that* is now also formally provided by JSR-286 and thus can be resolved in a JSR-286 native way too. HTH, Ate - Tor Iver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket portles in Sun Portal
Wilhelmsen Tor Iver wrote: To dig up this old thread: I now use Ate Douma's patch for JSR-286 support from https://issues.apache.org/jira/browse/WICKET-1620 which has removed the need for the portal to implement the Apache portlet bridge's two interfaces. A small step for man etc. :) Well, credits for those patches go to Thijs Vonk, I'm just the assignee of that issue :) Note though: those patches *as such* still need quite some refactoring (as already discussed on this list before) and the final JSR-286 support very likely will turn out a little bit different... For those who haven't discovered this yet, I might have a nice news update: JSR-286 has finally landed! See: http://jcp.org/aboutJava/communityprocess/final/jsr286/index.html There now is an issue - the same I had in JBoss - that it seems the bridge has a bug where the WicketFilterPortletContext call to ServletPortletSessionProxy.createProxy(filterRequestContext.getRequest() ) places a Double into the window-id propery that later will be cast to String... No. This is *not* a bug in the bridge, but one in their portlet container implementation. The method concerning this issue is o.a.p.bridges.util.PortletWindowUtils.getPortletWindowId(PortletSession) That method (which I wrote) is 100% following the JSR-168 specification, its just too bad JBoss Portal (and now it seems also Sun Portal) fail to follow those rules concerning this functionality. ... makes me wonder if they (now) share some common codebase ? ... Anyway, I know this is annoying and I could maybe "fix" this through a workaround (not sure yet though: this exception might indicate something more/worse is wrong, but I haven't debugged *their* engines yet). But... such a fix or workaround will take some time to formally "land" in a new release of bridges anyway, and maybe by that time this is moot if we have (basic) JSR-286 support in place for Wicket by then ... Are there plans to completely disconnect the Wicket portlet impl. from the bridge (i.e. including this dependency to ServletPortletSessionProxy)? Yes/no. JSR-286 support will no longer need/depend on the two ServletContextProvider and PortletResourceURLFactory implementations. Additionally, the ServletPortletSessionProxy functionality *might* be replaced by a native JSR-286 feature but... that is an optional feature of the spec, so it depends if the underlying portlet container does support it or not. If not, the ServletPortletSessionProxy (which provides exactly the same functionality as this optional feature... wonder how come?) will still be needed. But in that case, the part you encountered the exception in comes from determining the Portlet WindowId, and *that* is now also formally provided by JSR-286 and thus can be resolved in a JSR-286 native way too. HTH, Ate - Tor Iver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket portles in Sun Portal
To dig up this old thread: I now use Ate Douma's patch for JSR-286 support from https://issues.apache.org/jira/browse/WICKET-1620 which has removed the need for the portal to implement the Apache portlet bridge's two interfaces. A small step for man etc. :) There now is an issue - the same I had in JBoss - that it seems the bridge has a bug where the WicketFilterPortletContext call to ServletPortletSessionProxy.createProxy(filterRequestContext.getRequest() ) places a Double into the window-id propery that later will be cast to String... Are there plans to completely disconnect the Wicket portlet impl. from the bridge (i.e. including this dependency to ServletPortletSessionProxy)? - Tor Iver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SV: Wicket portles in Sun Portal
> For b) I hope to get started on that ASAP. Excellent news! :) (Since this is so significant for us I might have a go at adding the support later this week if I can wrap my head around the source and API docs... testing for the presence of the Portlet 2.0 API as you mentioned is probably the best approach.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket portles in Sun Portal
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]
Re: Wicket portles in Sun Portal
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]
Wicket portles in Sun Portal
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
