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]
