[
https://issues.apache.org/jira/browse/WICKET-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Vaynberg updated WICKET-2204:
----------------------------------
Fix Version/s: 1.5-M2
(was: 1.5-M1)
> 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.5-M2
>
> 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.
