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]
