[jira] Updated: (WICKET-2204) urlFor(IResourceListener.INTERFACE) returns different URLs

["Francisco Treacy (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WICKET-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Francisco Treacy updated WICKET-2204:
-------------------------------------

    Attachment: quickstart.zip

> 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
>         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.