[
https://issues.apache.org/jira/browse/WICKET-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702891#action_12702891
]
Juergen Donnerstag commented on WICKET-2204:
--------------------------------------------
The simple solution for Francisco's problem is to explicitly use
Page.setStateless(false). The page will be assumed stateful and bound to a
session and the correct URL (1) will be generated.
I reverted the change because I wasn't sure if using a IResourceListener
prevents in all cases the page from being stateless.
While spending several hours looking deeper into it, I discovered a bunch more
issues:
a) Stateless resources will create a BookmarkableListenerInterfaceRequestTarget
which honors e.g. IndexedParamUrlCodingStrategy. Stateful resource will use
ListenerInterfaceRequestTarget which does not honor
IndexedParamUrlCodingStrategy
b) because pathForTarget() in some of IndexedParamUrlCodingStrategy will return
a URL, a wicket:bookmarkablePage query parameter will not be added to the URL.
In cases wher pathForTarget() return null, the URL (2) mentioned by Francisco
will be generated. It contains the Page (needed for stateless pages) and the
resource listener. I've didn't dig deep enough if that realy was the intend and
if that is actually working.
c) Page which require PageParameter obviously don't work in the previous
example, since the (stateless) Page can not be instantiated.
I updated IndexedParamUrlCodingStrategyTest to show some if these problems.
> urlFor(IResourceListener.INTERFACE) returns different URLs
> ----------------------------------------------------------
>
> Key: WICKET-2204
> URL: https://issues.apache.org/jira/browse/WICKET-2204
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4-RC2
> Environment: Ubuntu 8.10 / Java 1.6.0_0-b12
> Reporter: Francisco Treacy
> Assignee: Juergen Donnerstag
> Fix For: 1.4-RC3
>
> Attachments: quickstart.zip
>
>
> When I call urlFor(IResourceListener.INTERFACE) in the renderHead method of
> my public abstract class SWFComponent extends WebMarkupContainer implements
> IResourceListener, IHeaderContributor
> it randomly returns two different type of URLs:
> 1. ?wicket:interface=:3:docsPanel:viewer:flash::IResourceListener:: ( this
> is the good URL I was expecting, that calls the onResourceRequested callback
> method)
> 2.
> ?wicket:bookmarkablePage=:app.wicket.document.DocumentDetailPage&wicket:interface=:10:detailPanel:viewer:flash::IResourceListener::
> (this bookmarkable link tries to point to the page that holds the instance
> of the SWFComponent - and fails because this page needs PageParameters- but
> is incorrect anyway)
> The 'randomness' seems be triggered after compilation - but is very difficult
> to reproduce. For example, after experiencing this strange behaviour in a
> development environment, I committed a "working" dev version (URL of type 1)
> to the continuous integration server. The integration app was running the
> same codebase but output URLs of type 2.
> I am attaching a quickstart that returns URLs of type 2 by the time I filed
> this issue. I tried digging into the WebRequestCodingStrategy but it was
> difficult to compare as I couldn't easily reproduce both types.
> In the quickstart I also included a splitted version of the component, i.e.
> a public abstract class SWFResourceListener extends WebMarkupContainer
> implements IResourceListener + a public class SWFBehavior extends
> AbstractBehavior implements IHeaderContributor
> in an unsuccessful attempt to see if the problem was caused by the fact of
> having component + header contributor + resource listener all in the same
> class.
> I have solved my case by swapping the IResourceListener for a plain old
> BookmarkablePage that outputs the SWF bytes, but I still think it's worth to
> have a look at this bizarre behaviour (which, by the way, might be related to
> WICKET-289 ?).
> Thanks
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
