Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Later
    • Affects Version/s: 1.5-RC7
    • Fix Version/s: None
    • Component/s: wicket
    • Labels:
      None

      Description

      Url returned by the RequestMapper does not seem to be properly rendered, as it does not encode question mark character in the Url parameter value (I haven't checked the w3c spec, but at least Liferay Portal seems to require it to be encoded)

      The reason is this definition in the UrlEncoder:
      case QUERY :
      // to allow direct passing of URL in query
      dontNeedEncoding.set('/');
      // to allow direct passing of URL in query
      dontNeedEncoding.set('?');

      Currently URL "http://host/file?param=a?b" would be encoded as "http://host/file?param=a?b", instead of "http://host/file?param=a%3Fb"

      1. wicket-portlet-1.5.7.2.zip
        33 kB
        Peter Pastrnak
      2. wicket-portlet-1.5.7.1.zip
        32 kB
        Peter Pastrnak
      3. wicket-portlet-1.5.5.1.zip
        33 kB
        Peter Pastrnak
      4. wicket-portlet-1.5.5.0.zip
        33 kB
        Peter Pastrnak
      5. wicket-portlet-1.5.2.4.zip
        33 kB
        Peter Pastrnak
      6. wicket-portlet-1.5.2.2.zip
        41 kB
        Peter Pastrnak
      7. wicket-1.5.2.1.zip
        42 kB
        Peter Pastrnak
      8. wicket-portlet-1.5.2.zip
        33 kB
        Peter Pastrnak
      9. wicket-portlet-1.5.1.5.zip
        32 kB
        Peter Pastrnak
      10. wicket-portlet-1.5.1.4.zip
        114 kB
        Peter Pastrnak
      11. PortletServletRequestWrapper.java
        8 kB
        Ronny Pscheidl
      12. wicket-portlet-1.5.1.3.zip
        111 kB
        Peter Pastrnak
      13. wicket-portlet-1.5.1.2.zip
        111 kB
        Peter Pastrnak
      14. wicket-portlet-1.5.1.1.zip
        111 kB
        Peter Pastrnak
      15. ASF.LICENSE.NOT.GRANTED--without bind(this).jpg
        63 kB
        Ronny Pscheidl
      16. ASF.LICENSE.NOT.GRANTED--with bind(this).jpg
        59 kB
        Ronny Pscheidl
      17. Wicket - Portlet.htm
        46 kB
        Ronny Pscheidl
      18. ResponseState.java
        18 kB
        Ronny Pscheidl
      19. wicket-portlet-1.5.1.zip
        110 kB
        Peter Pastrnak
      20. wicket-portlet-1.5.0.zip
        29 kB
        Peter Pastrnak
      21. wicket-portlet-1.5.RC7.zip
        29 kB
        Peter Pastrnak

        Activity

        Hide
        Martin Grigorov added a comment -

        Closing the ticket as "Later".
        The provided patch by Peter Pastrnak has been added to WicketStuff project - https://github.com/wicketstuff/core/tree/master/jdk-1.6-parent/portlet-parent.
        Since then it didn't get much attention so we think there is no reason to add it to the official Wicket distribution.

        Show
        Martin Grigorov added a comment - Closing the ticket as "Later". The provided patch by Peter Pastrnak has been added to WicketStuff project - https://github.com/wicketstuff/core/tree/master/jdk-1.6-parent/portlet-parent . Since then it didn't get much attention so we think there is no reason to add it to the official Wicket distribution.
        Hide
        Thijs Vonk added a comment -

        Hi Matthias,
        I'm also interested in the portlet project. I've forked your repro and started to re-configure my own test portlets. Hope to be able to spend some time on this the coming weeks

        Show
        Thijs Vonk added a comment - Hi Matthias, I'm also interested in the portlet project. I've forked your repro and started to re-configure my own test portlets. Hope to be able to spend some time on this the coming weeks
        Hide
        Matthias Gasser added a comment -

        Hi Marek,

        I'd welcome that. I've created a github repository too (forking includes the whole wicketstuff thing, I've tried to avoid that)

        https://github.com/matthiasgasser/wicket-portlet

        Feel free to evaluate my efforts, and maybe we'll have this up and running soon.

        thx

        Show
        Matthias Gasser added a comment - Hi Marek, I'd welcome that. I've created a github repository too (forking includes the whole wicketstuff thing, I've tried to avoid that) https://github.com/matthiasgasser/wicket-portlet Feel free to evaluate my efforts, and maybe we'll have this up and running soon. thx
        Hide
        Marek Šabo added a comment -

        Hi Matthias,

        I have forked repo on github with *wicketstuff / core / jdk-1.6-parent / portlet-paren* code merged with contents of wicket-portlet-1.5.7.2.zip attachment. I've not done any functional changes myself yet.

        We have wicket/portlet project in work and are currently advocating migration from Wicket 1.4 to 6 so we will need to make it work somehow. That being said, I would like to join effort in case I get green lights there.

        Show
        Marek Šabo added a comment - Hi Matthias, I have forked repo on github with * wicketstuff / core / jdk-1.6-parent / portlet-paren * code merged with contents of wicket-portlet-1.5.7.2.zip attachment. I've not done any functional changes myself yet. We have wicket/portlet project in work and are currently advocating migration from Wicket 1.4 to 6 so we will need to make it work somehow. That being said, I would like to join effort in case I get green lights there.
        Hide
        Matthias Gasser added a comment -

        I've tried to adopt the given wicket-portlet-1.5.7.2 for wicket 6 and tested on Liferay 6.1.1.

        To do so, I've migrated the files to go well with wicket 6.1.1.

        First things noticed:
        1) in the PortletFilter a new PortletRequestMapper wrapping a new SystemMapper, but doing so removes any custom mappings defined in the WebApplication init, which will turn in a StackOverflowException as no IRequestMapper is in charge handling the request.
        2) so preserved the "old" systemMapper within PortletRequestMapper: this.systemMapper = (SystemMapper) application.getRootRequestMapper();
        3) at this stage, ResourceURLs are missing the portleturl+wicketfilterurl but wicket portlets showing up again, however images are unrendered, any functionality posting forms / ajax are going for the wrong url.

        Did anybody else trying to adopt this for Wicket 6? Maybe we can share our experience and make the portlet module wicket 6 ready.

        Thx,

        Show
        Matthias Gasser added a comment - I've tried to adopt the given wicket-portlet-1.5.7.2 for wicket 6 and tested on Liferay 6.1.1. To do so, I've migrated the files to go well with wicket 6.1.1. First things noticed: 1) in the PortletFilter a new PortletRequestMapper wrapping a new SystemMapper, but doing so removes any custom mappings defined in the WebApplication init, which will turn in a StackOverflowException as no IRequestMapper is in charge handling the request. 2) so preserved the "old" systemMapper within PortletRequestMapper: this.systemMapper = (SystemMapper) application.getRootRequestMapper(); 3) at this stage, ResourceURLs are missing the portleturl+wicketfilterurl but wicket portlets showing up again, however images are unrendered, any functionality posting forms / ajax are going for the wrong url. Did anybody else trying to adopt this for Wicket 6? Maybe we can share our experience and make the portlet module wicket 6 ready. Thx,
        Hide
        Peter Pastrnak added a comment -

        fyi. wicketstuff portlet 1.5.8 is going to be broken too, because of one last minute change while back-porting it to java 1.5 (not done by me, but caused by me, as i did use java 1.6 in the 1.5 branch). so the only stable version is still 1.5.7.2, that can be downloaded from here.

        Show
        Peter Pastrnak added a comment - fyi. wicketstuff portlet 1.5.8 is going to be broken too, because of one last minute change while back-porting it to java 1.5 (not done by me, but caused by me, as i did use java 1.6 in the 1.5 branch). so the only stable version is still 1.5.7.2, that can be downloaded from here.
        Hide
        Gabriel Landon added a comment -

        Peter, I've tested the wicket-portlet-1.5.7.2 and it's working great with liferay 6.1.
        All the troubles I used to have with the previous version (with ajax) are gone.

        Thank you.

        Show
        Gabriel Landon added a comment - Peter, I've tested the wicket-portlet-1.5.7.2 and it's working great with liferay 6.1. All the troubles I used to have with the previous version (with ajax) are gone. Thank you.
        Hide
        Martin Grigorov added a comment -

        Actually Wicket Ajax sets the request parameters when submitting a form because the submit is done with an iframe and there is no way to set headers in this case. The headers are set only when XmlHttpRequest is used (i.e. non-multipart requests).

        Thanks for updating the GitHub!
        I've built 1.5.7 yesterday so it includes the old code but 1.5.8 will have the new one!
        http://repo1.maven.org/maven2/org/wicketstuff/wicketstuff-portlet/1.5.7/

        Show
        Martin Grigorov added a comment - Actually Wicket Ajax sets the request parameters when submitting a form because the submit is done with an iframe and there is no way to set headers in this case. The headers are set only when XmlHttpRequest is used (i.e. non-multipart requests). Thanks for updating the GitHub! I've built 1.5.7 yesterday so it includes the old code but 1.5.8 will have the new one! http://repo1.maven.org/maven2/org/wicketstuff/wicketstuff-portlet/1.5.7/
        Hide
        Peter Pastrnak added a comment -

        This time a tested fix for the multipart support (last one did not work properly). The whole problem is, that wicket javascript library adds "wicket-ajax-*" parameters to the form action (instead of headers), so we have to include these parameters in the wicket url when doing the include.
        Martin, thank you for the detailed description. I have commited the latest sources to github (core-1.5.x).

        Show
        Peter Pastrnak added a comment - This time a tested fix for the multipart support (last one did not work properly). The whole problem is, that wicket javascript library adds "wicket-ajax-*" parameters to the form action (instead of headers), so we have to include these parameters in the wicket url when doing the include. Martin, thank you for the detailed description. I have commited the latest sources to github (core-1.5.x).
        Hide
        Martin Grigorov added a comment -

        Here is a simple howto work with GitHub/Git so you can move your patches in the repo.

        1) git clone https://github.com/wicketstuff/core.git (you need to do this just once. it is like 'svn checkout url')
        2) git checkout core-1.5.x (this will switch to Wicket 1.5 branch of the project)
        3) cd jdk-1.5-parent/portlet-parent/wicketstuff-portlet
        4) edit the files
        5) git ci -a (this is like 'svn commit' but it commits just locally)
        6) git push (this uploads the commits in your local repo to the main repo)

        That's it.
        I hope you don't have problem with using the command line Git client. You can use your favorite IDE if you want but I think there is no reason to "pollute" your IDE with plugins just for a single commit/push that you do once in a while.

        Show
        Martin Grigorov added a comment - Here is a simple howto work with GitHub/Git so you can move your patches in the repo. 1) git clone https://github.com/wicketstuff/core.git (you need to do this just once. it is like 'svn checkout url') 2) git checkout core-1.5.x (this will switch to Wicket 1.5 branch of the project) 3) cd jdk-1.5-parent/portlet-parent/wicketstuff-portlet 4) edit the files 5) git ci -a (this is like 'svn commit' but it commits just locally) 6) git push (this uploads the commits in your local repo to the main repo) That's it. I hope you don't have problem with using the command line Git client. You can use your favorite IDE if you want but I think there is no reason to "pollute" your IDE with plugins just for a single commit/push that you do once in a while.
        Hide
        Peter Pastrnak added a comment -

        Sorry, but the last update (1.5.5.2) broke multipart support and maybe some other things. This update (1.5.7.1) should fix it. I've narrowed adding proprietary query parameters only to resource requests with GET method - it should be enough for all Ajax requests and should not have any influence on standard form submits.

        But if you don't need this feature at all (e.g. all your ajax handlers / components dont use getQueryParameters [just getRequestParameters] or your javascripts are clever enough not to add any proprietary parameters to the url, you can comment out lines 306-323 in WicketPortlet.java.

        Show
        Peter Pastrnak added a comment - Sorry, but the last update (1.5.5.2) broke multipart support and maybe some other things. This update (1.5.7.1) should fix it. I've narrowed adding proprietary query parameters only to resource requests with GET method - it should be enough for all Ajax requests and should not have any influence on standard form submits. But if you don't need this feature at all (e.g. all your ajax handlers / components dont use getQueryParameters [just getRequestParameters] or your javascripts are clever enough not to add any proprietary parameters to the url, you can comment out lines 306-323 in WicketPortlet.java.
        Hide
        Peter Pastrnak added a comment -

        Gabriel, if you want to put it to wicket stuff, just ask for access and do it. The problem is that I'm not familiar with wicket github structure (and git in general) and I don't know where to put it and how. I only upload here fixes for the version we are currently using (1.5.5) and I cannot maintain / test it for the latest wicket version. It is just impossible without unit tests that would be part of the build.

        Show
        Peter Pastrnak added a comment - Gabriel, if you want to put it to wicket stuff, just ask for access and do it. The problem is that I'm not familiar with wicket github structure (and git in general) and I don't know where to put it and how. I only upload here fixes for the version we are currently using (1.5.5) and I cannot maintain / test it for the latest wicket version. It is just impossible without unit tests that would be part of the build.
        Hide
        Peter Pastrnak added a comment -

        Little 'hack' to fix the problem with form submit, when there is a parameter, that needs an URL encoding. Now parameters, that are added by javascript to the URL, but not to the "_wu" parameter, will become part of the query parameters only in case of a GET request. There is no perfect solution for this, as we do not have control over the javascript library, to force it to add parameters to the _wu parameter instead of adding a new parameter. This way for GET requests we merge the URL parameters with the _wu parameter and for all other HTTP methods we use only the query parameters, that are contained in the _wu url. ('standalone' parameters added by javascript will be accessible still accessible as POST parameters.)

        Show
        Peter Pastrnak added a comment - Little 'hack' to fix the problem with form submit, when there is a parameter, that needs an URL encoding. Now parameters, that are added by javascript to the URL, but not to the "_wu" parameter, will become part of the query parameters only in case of a GET request. There is no perfect solution for this, as we do not have control over the javascript library, to force it to add parameters to the _wu parameter instead of adding a new parameter. This way for GET requests we merge the URL parameters with the _wu parameter and for all other HTTP methods we use only the query parameters, that are contained in the _wu url. ('standalone' parameters added by javascript will be accessible still accessible as POST parameters.)
        Hide
        Gabriel Landon added a comment -

        Also beware that the wicket-stuff-portlet code is not up to date. You have to use the wicket-portlet-1.5.5.0.zip file that is in this ticket. I've lost a whole day to find that out!
        Can, someone with wicketstuff acces, please update the repo?

        Show
        Gabriel Landon added a comment - Also beware that the wicket-stuff-portlet code is not up to date. You have to use the wicket-portlet-1.5.5.0.zip file that is in this ticket. I've lost a whole day to find that out! Can, someone with wicketstuff acces, please update the repo?
        Hide
        Martin Grigorov added a comment -

        See http://markmail.org/thread/uetjc6xo2xse3r2j for a solution for a missing url-mapping in Liferay 6.1.

        Show
        Martin Grigorov added a comment - See http://markmail.org/thread/uetjc6xo2xse3r2j for a solution for a missing url-mapping in Liferay 6.1.
        Hide
        Peter Pastrnak added a comment -

        Some release after 1.5.2 broke the portlet support. The reason was a change in the ServletWebRequest class, that started to check whether it is an http forward request or not (checking all forward request attributes). This little upgrade should fix this issue.

        Show
        Peter Pastrnak added a comment - Some release after 1.5.2 broke the portlet support. The reason was a change in the ServletWebRequest class, that started to check whether it is an http forward request or not (checking all forward request attributes). This little upgrade should fix this issue.
        Hide
        Peter Pastrnak added a comment -

        I'm really sorry for this, but it seems, I cant find time to have a look at how git / github with eclipse / svn works, so I decided to at least upload the fixes I mentioned in November. Better upload something than nothing...

        Show
        Peter Pastrnak added a comment - I'm really sorry for this, but it seems, I cant find time to have a look at how git / github with eclipse / svn works, so I decided to at least upload the fixes I mentioned in November. Better upload something than nothing...
        Hide
        Peter Pastrnak added a comment -

        Finally i had time to have a look at the query vs. post parameters problem and I've realized that there is no access to them in the include, but they are accessible in the portlet, so the patch was simple, I just had to include (merge) the portlet request parameters in the url that is forwarded (using include) to the filter. I've also found out, that without this fix, every ajax multipart submit creates a new version of the page, as it sends 'wicket-ajax=true' as GET parameters.
        Also, I guess, version 1.5.2 started prepending the portlet namespace to a replaced component twice, as it reuses the old markupId and calls the onInitializationListener again. To fix this, I've just added a check, if the prefix is already there.
        As soon as I get the commit access on wicket stuff, I can commit these 2 fixes.

        As the request query parameters are available in portlet, it would be definitely worth to get rid off the filter in the portlet support and then remove the unnecessary response caching. It could bring nice performance increase, simpler code and one step easier configuration. But for this I need 1-2 days plus run some tests, so maybe I'll have a look at it in December...

        I use this page as a notepad (sorry for that), so don't bother reacting... Maybe once I'll start writing a wiki page ...

        Show
        Peter Pastrnak added a comment - Finally i had time to have a look at the query vs. post parameters problem and I've realized that there is no access to them in the include, but they are accessible in the portlet, so the patch was simple, I just had to include (merge) the portlet request parameters in the url that is forwarded (using include) to the filter. I've also found out, that without this fix, every ajax multipart submit creates a new version of the page, as it sends 'wicket-ajax=true' as GET parameters. Also, I guess, version 1.5.2 started prepending the portlet namespace to a replaced component twice, as it reuses the old markupId and calls the onInitializationListener again. To fix this, I've just added a check, if the prefix is already there. As soon as I get the commit access on wicket stuff, I can commit these 2 fixes. As the request query parameters are available in portlet, it would be definitely worth to get rid off the filter in the portlet support and then remove the unnecessary response caching. It could bring nice performance increase, simpler code and one step easier configuration. But for this I need 1-2 days plus run some tests, so maybe I'll have a look at it in December... I use this page as a notepad (sorry for that), so don't bother reacting... Maybe once I'll start writing a wiki page ...
        Hide
        Igor Vaynberg added a comment -

        if you have a better way to do it then go for it. i think it uses filter because it started out as a bridge impl before it was a full blown one.

        Show
        Igor Vaynberg added a comment - if you have a better way to do it then go for it. i think it uses filter because it started out as a bridge impl before it was a full blown one.
        Hide
        Peter Pastrnak added a comment -

        thank you, for the tagit.

        i'm thinking about rewriting the portlet support, to not use the wicket filter at all and copy some of the functionality to the wicket portlet (that can be generalized later, if possible).

        i don't see any reason, why do we have to use dispatcher.include at all, as we could create the request cycle directly in the portlet. any idea why was it done this way? there will be for sure some problems with package visibility, but this is resolvable. and we might loose the option to access url parameters generated by a javascript completely, but this is not allowed by the portlet spec anyway, so we should solve it different way.

        Show
        Peter Pastrnak added a comment - thank you, for the tagit. i'm thinking about rewriting the portlet support, to not use the wicket filter at all and copy some of the functionality to the wicket portlet (that can be generalized later, if possible). i don't see any reason, why do we have to use dispatcher.include at all, as we could create the request cycle directly in the portlet. any idea why was it done this way? there will be for sure some problems with package visibility, but this is resolvable. and we might loose the option to access url parameters generated by a javascript completely, but this is not allowed by the portlet spec anyway, so we should solve it different way.
        Hide
        Martin Grigorov added a comment -

        OK, I updated Autocomplete-TagIt to look for 'term' parameter both in GET and POST. Enjoy!

        Show
        Martin Grigorov added a comment - OK, I updated Autocomplete-TagIt to look for 'term' parameter both in GET and POST. Enjoy!
        Hide
        Peter Pastrnak added a comment -

        1.5.2.2. - last version here, next week i'll switch to wicketstuff. We definitely need some unit tests, in the last version (1.5.2.1) i tried to fix the GET vs. POST parameters problem with parameters added by javascript (found in TagIt), but it broke too many other things. It does not seem to be easy to reconstruct the original querystring, so i better leave this for now, as it was (as this is most probably container dependent). That means the parameter will be in the parameterMap, but not in the querystring and Wicket will recognize these parameters as POST parameters.
        I have to check this in the spec, but I guess, that correct solution might be to prefix all these parameters with the portlet namespace, because normally you should not have access to these parameters at all.
        Martin, if you could change the TagIt component to accept both types, it would be the best.

        Show
        Peter Pastrnak added a comment - 1.5.2.2. - last version here, next week i'll switch to wicketstuff. We definitely need some unit tests, in the last version (1.5.2.1) i tried to fix the GET vs. POST parameters problem with parameters added by javascript (found in TagIt), but it broke too many other things. It does not seem to be easy to reconstruct the original querystring, so i better leave this for now, as it was (as this is most probably container dependent). That means the parameter will be in the parameterMap, but not in the querystring and Wicket will recognize these parameters as POST parameters. I have to check this in the spec, but I guess, that correct solution might be to prefix all these parameters with the portlet namespace, because normally you should not have access to these parameters at all. Martin, if you could change the TagIt component to accept both types, it would be the best.
        Hide
        Martin Grigorov added a comment -

        I just added it: https://github.com/wicketstuff/core/tree/master/jdk-1.5-parent/portlet-parent
        Now it will be part of the WicketStuff release process and will be deployed at Maven repos (http://repo1.maven.org/maven2/org/wicketstuff/) soon after each release of Wicket itself.

        Steps to do:

        • create an account at GitHub
        • send an email to the wicket developer mailing list with a subject of Wicket Stuff commit access and your github.com username.
        • add a Wiki page at https://github.com/wicketstuff/core/wiki for Portlet - with description what it is, how to use it, ...
        • continue improving the project

        Read https://github.com/wicketstuff/core/wiki for more info.

        Show
        Martin Grigorov added a comment - I just added it: https://github.com/wicketstuff/core/tree/master/jdk-1.5-parent/portlet-parent Now it will be part of the WicketStuff release process and will be deployed at Maven repos ( http://repo1.maven.org/maven2/org/wicketstuff/ ) soon after each release of Wicket itself. Steps to do: create an account at GitHub send an email to the wicket developer mailing list with a subject of Wicket Stuff commit access and your github.com username. add a Wiki page at https://github.com/wicketstuff/core/wiki for Portlet - with description what it is, how to use it, ... continue improving the project Read https://github.com/wicketstuff/core/wiki for more info.
        Hide
        Peter Pastrnak added a comment -

        martin, if you give me exact description (or some pointers) how to set what, i can ask someone to do it, because currently I don't have time to set it up. I always have 1-2 hours to quick fix something and it is not too much pain for me to export it from our svn / nexus and put it here.
        igor, thanks for the encoder fix, i hope it wont break something else (we use it that way, even in production already and everything works fine).

        Show
        Peter Pastrnak added a comment - martin, if you give me exact description (or some pointers) how to set what, i can ask someone to do it, because currently I don't have time to set it up. I always have 1-2 hours to quick fix something and it is not too much pain for me to export it from our svn / nexus and put it here. igor, thanks for the encoder fix, i hope it wont break something else (we use it that way, even in production already and everything works fine).
        Hide
        Martin Grigorov added a comment -

        I see that the last attache .zip is actually Maven project.
        I think it will be good if we add it as a sub-module in wicketstuff for while, to incubate.
        This way other users can try it on different containers than Liferay 6.x.

        Show
        Martin Grigorov added a comment - I see that the last attache .zip is actually Maven project. I think it will be good if we add it as a sub-module in wicketstuff for while, to incubate. This way other users can try it on different containers than Liferay 6.x.
        Hide
        Martin Grigorov added a comment -

        if it is possible to isolate all classes needed for Portlet support in a separate Maven module will be the best.

        Show
        Martin Grigorov added a comment - if it is possible to isolate all classes needed for Portlet support in a separate Maven module will be the best.
        Hide
        Igor Vaynberg added a comment -

        peter: ive disable the encoding of the question mark in the latest rev. however, if this causes problems for non-portlet envs i will revert the change and we will have to figure out a switch somewhere.

        Show
        Igor Vaynberg added a comment - peter: ive disable the encoding of the question mark in the latest rev. however, if this causes problems for non-portlet envs i will revert the change and we will have to figure out a switch somewhere.
        Hide
        Igor Vaynberg added a comment -

        peter arent you better off cloning our repo on github and maintaining your changes in a branch there rather then via these patches. it will make it much simpler for you to keep it up to date.

        Show
        Igor Vaynberg added a comment - peter arent you better off cloning our repo on github and maintaining your changes in a branch there rather then via these patches. it will make it much simpler for you to keep it up to date.
        Hide
        Peter Pastrnak added a comment -

        1.5.2.1 - Small fix (workaround) for Javascript based components (like TagIt).

        Show
        Peter Pastrnak added a comment - 1.5.2.1 - Small fix (workaround) for Javascript based components (like TagIt).
        Hide
        Peter Pastrnak added a comment -

        Any chance to have a look at my original request about the UrlRenderer (support for legacy systems), that I don't have to patch the 'portlet-request' artifact every time?

        (Currently URL "http://host/file?param=a?b" would be encoded as "http://host/file?param=a?b", instead of "http://host/file?param=a%3Fb".)

        Show
        Peter Pastrnak added a comment - Any chance to have a look at my original request about the UrlRenderer (support for legacy systems), that I don't have to patch the 'portlet-request' artifact every time? (Currently URL "http://host/file?param=a?b" would be encoded as "http://host/file?param=a?b", instead of "http://host/file?param=a%3Fb".)
        Hide
        Peter Pastrnak added a comment -

        1.5.2 - Response buffer (cache) directory is now taken from the servlet context and can be overridden using 'responseBufferFolder' portlet parameters. Response buffer is deleted after it is committed to the response (or when finalize is called). Dependency was changed (and tested) to 1.5.2.

        Show
        Peter Pastrnak added a comment - 1.5.2 - Response buffer (cache) directory is now taken from the servlet context and can be overridden using 'responseBufferFolder' portlet parameters. Response buffer is deleted after it is committed to the response (or when finalize is called). Dependency was changed (and tested) to 1.5.2.
        Hide
        Peter Pastrnak added a comment - - edited

        Finally I've realized, why the whole response has to be cached (as it was in wicket portlet 1.4). WicketPortlet uses dispatcher.include to 'forward' the request to the WicketFilter and as the servlet specification does not allow setting headers (e.g. contentType) inside an include, the response has to be cached and flushed just after the include ends. It is currently not possible to use the dispatcher.forward instead of the include, as after the forward would be the response closed and it would not be possible to do another forward (after wicket redirect). We could try to find some workaround, but it is easier to implement a file system cache for this, so I've reverted the flushing mechanism and implemented a simple file system cache that uses File.createTempFile (might be changed in the future) as soon as the response reaches a limit (currently set to 64kB).

        Show
        Peter Pastrnak added a comment - - edited Finally I've realized, why the whole response has to be cached (as it was in wicket portlet 1.4). WicketPortlet uses dispatcher.include to 'forward' the request to the WicketFilter and as the servlet specification does not allow setting headers (e.g. contentType) inside an include, the response has to be cached and flushed just after the include ends. It is currently not possible to use the dispatcher.forward instead of the include, as after the forward would be the response closed and it would not be possible to do another forward (after wicket redirect). We could try to find some workaround, but it is easier to implement a file system cache for this, so I've reverted the flushing mechanism and implemented a simple file system cache that uses File.createTempFile (might be changed in the future) as soon as the response reaches a limit (currently set to 64kB).
        Hide
        Peter Pastrnak added a comment -

        I just know, that with 1.5.0 our error pages, that are served with a simple page provider returned by an exception mapper, used to be rendered as stateful and since 1.5.1 they are rendered as stateless. But anyway, they supposed to be marked as stateful, so it was our fault.

        I'll try the snapshot hopefully by the end of the week. Can this fix the 'problem' with buffering and 'redirect-to-render' strategy? (That it does not store the pages in the buffer.)

        Show
        Peter Pastrnak added a comment - I just know, that with 1.5.0 our error pages, that are served with a simple page provider returned by an exception mapper, used to be rendered as stateful and since 1.5.1 they are rendered as stateless. But anyway, they supposed to be marked as stateful, so it was our fault. I'll try the snapshot hopefully by the end of the week. Can this fix the 'problem' with buffering and 'redirect-to-render' strategy? (That it does not store the pages in the buffer.)
        Hide
        Martin Grigorov added a comment -

        You are not right
        With WICKET-3991 more pages were rendered as "stateful", not as "stateless".

        The change in WICKET-3991 has been reverted partially for 1.5.2 and now only "setResponsePage(pageInstance)" marks 'pageInstance' as stateful explicitly, so that it will be stored in the page stores and using F5 (reload the page) will still work.
        Try with latest 1.5-SNAPSHOT if you can and give us feedback. Thanks!

        Show
        Martin Grigorov added a comment - You are not right With WICKET-3991 more pages were rendered as "stateful", not as "stateless". The change in WICKET-3991 has been reverted partially for 1.5.2 and now only "setResponsePage(pageInstance)" marks 'pageInstance' as stateful explicitly, so that it will be stored in the page stores and using F5 (reload the page) will still work. Try with latest 1.5-SNAPSHOT if you can and give us feedback. Thanks!
        Hide
        Peter Pastrnak added a comment -

        Since wicket-core 1.5.1 we've got much more pages rendered as stateless. What, I believe, is because the PageProvider has changed and the stateless hint is not set in the constructor anymore "((Page)pageInstance).setStatelessHint(false);". Now, if a page is bookmarkable (e.g. has the default constructor) and no stateful hint is explicitly set and has no stateful component, then it is stateless. So if I add a page like this to the ajaxrequesttarget or i return it as a reference wrapped by a pageprovider, it will be stored as a buffered response and after the redirect returned from this buffer to the user.

        I know, that it is probably my duty to tell Wicket that it should not try to render a page like this as a stateless page (e.g. by not adding the default contructor or explicitly setting the hint), but my problem is that these pages will be rendered differently in portlet container and in a standard servlet environment. The reason is the "redirect-to-render" strategy, that is used by the portlet bridge and that makes the WebPageRenderer to not store a page like this in the response buffer, causing "PageExpiredException" in the portlet container case...

        On the other hand, is it correct, that page instances are not stored in a pagestore in this case? I know I probably should not redirect to instances of a stateless page, but what if I do? This page can be returned from the buffered response only once...

        It might be, that I haven't investigated enough, so just tell me if I'm not right .

        Show
        Peter Pastrnak added a comment - Since wicket-core 1.5.1 we've got much more pages rendered as stateless. What, I believe, is because the PageProvider has changed and the stateless hint is not set in the constructor anymore "((Page)pageInstance).setStatelessHint(false);". Now, if a page is bookmarkable (e.g. has the default constructor) and no stateful hint is explicitly set and has no stateful component, then it is stateless. So if I add a page like this to the ajaxrequesttarget or i return it as a reference wrapped by a pageprovider, it will be stored as a buffered response and after the redirect returned from this buffer to the user. I know, that it is probably my duty to tell Wicket that it should not try to render a page like this as a stateless page (e.g. by not adding the default contructor or explicitly setting the hint), but my problem is that these pages will be rendered differently in portlet container and in a standard servlet environment. The reason is the "redirect-to-render" strategy, that is used by the portlet bridge and that makes the WebPageRenderer to not store a page like this in the response buffer, causing "PageExpiredException" in the portlet container case... On the other hand, is it correct, that page instances are not stored in a pagestore in this case? I know I probably should not redirect to instances of a stateless page, but what if I do? This page can be returned from the buffered response only once... It might be, that I haven't investigated enough, so just tell me if I'm not right .
        Hide
        Peter Pastrnak added a comment -

        Changes in version 1.5.1.4:
        1. getHeader, getHeaders calls are not case sensitive (workaround for GateIn Portal)
        2. Parameters added by Javascript (not in the resourceId) are part of the queryString, so they are not treated as Post parameters anymore.
        3. Portlet bridge should detect Ajax redirects and correct the URL.
        4. All Wicket request parameters (that are properly namespaced) are stripped from the generated resourceUrl (as they belong to the request and should not affect the generated URL).

        Show
        Peter Pastrnak added a comment - Changes in version 1.5.1.4: 1. getHeader, getHeaders calls are not case sensitive (workaround for GateIn Portal) 2. Parameters added by Javascript (not in the resourceId) are part of the queryString, so they are not treated as Post parameters anymore. 3. Portlet bridge should detect Ajax redirects and correct the URL. 4. All Wicket request parameters (that are properly namespaced) are stripped from the generated resourceUrl (as they belong to the request and should not affect the generated URL).
        Hide
        Ronny Pscheidl added a comment - - edited

        Hello Peter,
        i have tested a lot. generated urls and ids are not the problem. The problem ist the bind method. in gatein there comes an Util.js in html header which define the bind method like this:

        Function.prototype.bind = function(object) {
        var method = this;
        return function()

        { method.apply(object, arguments); }

        }

        i have searched the bind definition in wicket-ajax an find this:

        if (Function.prototype.bind == null) {
        Function.prototype.bind = function(object) {
        var __method = this;
        return function()

        { return __method.apply(object, arguments); }

        }
        }

        if i call without container then i use the javascript engine bind function because Function.prototype.bind == null is false. with portal container the Util.js form gatein sets this function every time. i have openend a ticket for gatein (see https://issues.jboss.org/browse/GTNPORTAL-2167 for workaround) to set also this if condition before bind.

        The problem with the header params is also a gatein problem. The problem is that SimpleMultiValuedPropertyMap from gatein which holds in portalcontainer the headers does not load values with equalsIgnoreCase like MimeHeaders do in Request. i have implemented the two methods getHeader, getHeaders in PortletServletRequestWrapper. maybe you could update the attached class in wicket-portlet. (see also https://issues.jboss.org/browse/GTNPORTAL-2169)

        Show
        Ronny Pscheidl added a comment - - edited Hello Peter, i have tested a lot. generated urls and ids are not the problem. The problem ist the bind method. in gatein there comes an Util.js in html header which define the bind method like this: Function.prototype.bind = function(object) { var method = this; return function() { method.apply(object, arguments); } } i have searched the bind definition in wicket-ajax an find this: if (Function.prototype.bind == null) { Function.prototype.bind = function(object) { var __method = this; return function() { return __method.apply(object, arguments); } } } if i call without container then i use the javascript engine bind function because Function.prototype.bind == null is false. with portal container the Util.js form gatein sets this function every time. i have openend a ticket for gatein (see https://issues.jboss.org/browse/GTNPORTAL-2167 for workaround) to set also this if condition before bind. The problem with the header params is also a gatein problem. The problem is that SimpleMultiValuedPropertyMap from gatein which holds in portalcontainer the headers does not load values with equalsIgnoreCase like MimeHeaders do in Request. i have implemented the two methods getHeader, getHeaders in PortletServletRequestWrapper. maybe you could update the attached class in wicket-portlet. (see also https://issues.jboss.org/browse/GTNPORTAL-2169 )
        Hide
        Peter Pastrnak added a comment -

        1.5.1.3 - initial length of response buffer set to 1024 with flush length at 64 * 1024.

        Show
        Peter Pastrnak added a comment - 1.5.1.3 - initial length of response buffer set to 1024 with flush length at 64 * 1024.
        Hide
        Peter Pastrnak added a comment - - edited

        I checked https://issues.apache.org/jira/browse/WICKET-4113 and one reason, why it is cached might be, that if someone calls 'setResponsePage' when processing an Ajax request, portlet bridge does not return the original ajax redirect, instead it forwards the redirect to the wicket filter and renders the page to the response. But as these responses are always text based, I don't see any reason for binary responses to be cached (but I might be wrong ).
        Anyway, as I see this as a quite big issue, I've modified the ResponseState and created new version 5.2.1.2, that flushes the response (text and binary) every 256kB (can be changed per request using Response.getContainerResponse().setBufferSize()).

        Show
        Peter Pastrnak added a comment - - edited I checked https://issues.apache.org/jira/browse/WICKET-4113 and one reason, why it is cached might be, that if someone calls 'setResponsePage' when processing an Ajax request, portlet bridge does not return the original ajax redirect, instead it forwards the redirect to the wicket filter and renders the page to the response. But as these responses are always text based, I don't see any reason for binary responses to be cached (but I might be wrong ). Anyway, as I see this as a quite big issue, I've modified the ResponseState and created new version 5.2.1.2, that flushes the response (text and binary) every 256kB (can be changed per request using Response.getContainerResponse().setBufferSize()).
        Hide
        Peter Pastrnak added a comment - - edited

        Wicket-portlet generates for ajax calls (GET) portlet resource URL, that contains the real wicket URL encoded in a 'resource_id' parameter. PortletServletRequestWrapper currently returns inconsistent result, where getParameterMap is taken from the original HttpServletRequest and getQueryString is taken from the 'resource_id' parameter (from the included request). Wicket core parses the query string and all parameters that are in the parameter map and not in the query string are assigned to the 'post' group. So currently all javascript added parameters are treated as 'post' parameters and not 'query' parameters. As TagIt component adds the 'term' parameter at the end of the URL...

        Thats why I'm thinking about merging the parameters from URL and from the resource_id. Hopefully next week ill find some time to have a closer look at it.

        Example of the generated URL:

        https://www.domain.loc/apps/mail/sms/nova-sprava/-/newSms?p_p_id=NewSmsPortlet_WAR_mailportlet&p_p_lifecycle=2&p_p_state=normal&p_p_mode=view&p_p_resource_id=%2FNewSmsPortlet%2F%3F0-1.IBehaviorListener.0-sendingForm-recipients&p_p_cacheability=cacheLevelPage&p_p_col_id=column-3&p_p_col_count=1&term=XXXXX

        Show
        Peter Pastrnak added a comment - - edited Wicket-portlet generates for ajax calls (GET) portlet resource URL, that contains the real wicket URL encoded in a 'resource_id' parameter. PortletServletRequestWrapper currently returns inconsistent result, where getParameterMap is taken from the original HttpServletRequest and getQueryString is taken from the 'resource_id' parameter (from the included request). Wicket core parses the query string and all parameters that are in the parameter map and not in the query string are assigned to the 'post' group. So currently all javascript added parameters are treated as 'post' parameters and not 'query' parameters. As TagIt component adds the 'term' parameter at the end of the URL... Thats why I'm thinking about merging the parameters from URL and from the resource_id. Hopefully next week ill find some time to have a closer look at it. Example of the generated URL: https://www.domain.loc/apps/mail/sms/nova-sprava/-/newSms?p_p_id=NewSmsPortlet_WAR_mailportlet&p_p_lifecycle=2&p_p_state=normal&p_p_mode=view&p_p_resource_id=%2FNewSmsPortlet%2F%3F0-1.IBehaviorListener.0-sendingForm-recipients&p_p_cacheability=cacheLevelPage&p_p_col_id=column-3&p_p_col_count=1&term=XXXXX
        Hide
        Martin Grigorov added a comment -

        Someone bugged me in GitHub about this problem in TagIt but since I have no explanation of the reason for this problem I didn't do it. If you can explain me why a parameter from the Url is not in the query parameters, but in post parameters then I'll rework it.

        I would also want to ask you to take a look at https://issues.apache.org/jira/browse/WICKET-4113 and give your opinion on it. I see the same code is used in 1.5.

        Show
        Martin Grigorov added a comment - Someone bugged me in GitHub about this problem in TagIt but since I have no explanation of the reason for this problem I didn't do it. If you can explain me why a parameter from the Url is not in the query parameters, but in post parameters then I'll rework it. I would also want to ask you to take a look at https://issues.apache.org/jira/browse/WICKET-4113 and give your opinion on it. I see the same code is used in 1.5.
        Hide
        Peter Pastrnak added a comment -

        Version 1.5.1 was based on wrong branch, so it did not include changes from 1.5.0. This one should be a correct merge (the only changed class was the MarkupIdPrepender). We will run some tests today and tomorrow.
        I've noticed, that some components with ajax behaviour add a parameter to the generated resource url, that is not accessible using Request.getQueryParameters, only by getPostParameters or getRequestParameters. The reason is that the method call getQueryString and getParameterMap of PortletServletRequestWrapper are inconsistent. I guess there was the same problem in version 1.4.
        We've experienced this problem in TagIt component, that uses Request.getQueryParameters method. Similar component - Autocomplete in wicket-extensions works fine, as it uses Request.getRequestParameters. The solution could be that the PortletServletRequestWrapper would merge parameters from the url with wicket resource url parameters. Maybe I'll find some time next week to investigate a little more and fix it, because this makes some components unusable.

        Show
        Peter Pastrnak added a comment - Version 1.5.1 was based on wrong branch, so it did not include changes from 1.5.0. This one should be a correct merge (the only changed class was the MarkupIdPrepender). We will run some tests today and tomorrow. I've noticed, that some components with ajax behaviour add a parameter to the generated resource url, that is not accessible using Request.getQueryParameters, only by getPostParameters or getRequestParameters. The reason is that the method call getQueryString and getParameterMap of PortletServletRequestWrapper are inconsistent. I guess there was the same problem in version 1.4. We've experienced this problem in TagIt component, that uses Request.getQueryParameters method. Similar component - Autocomplete in wicket-extensions works fine, as it uses Request.getRequestParameters. The solution could be that the PortletServletRequestWrapper would merge parameters from the url with wicket resource url parameters. Maybe I'll find some time next week to investigate a little more and fix it, because this makes some components unusable.
        Hide
        Peter Pastrnak added a comment -

        ronny, about the precondition problem. if you are sure that everything works without the portlet container (and wicket portlet), then just try to find the difference between the generated htmls (with and without the container), that causes the problem. the differences should be mainly in the generated IDs and URLs, so usually the problem is that either one of the javascript libraries is not loaded or browser cannot correctly interpret the url / id. But you should use the wicket-portlet 1.5.1 version, as the previous versions have IDs for all tags.
        thats why i suggested to disable the MarkupIdPrepender, because then you shoul dhave the same IDs as without the portlet container. The only differences will be in the URLs. Also check if there is the same problem using any browser (I would test it f.e. on firefox first with firebug plugin enabled, that you see all the errors and unloaded libraries).

        Show
        Peter Pastrnak added a comment - ronny, about the precondition problem. if you are sure that everything works without the portlet container (and wicket portlet), then just try to find the difference between the generated htmls (with and without the container), that causes the problem. the differences should be mainly in the generated IDs and URLs, so usually the problem is that either one of the javascript libraries is not loaded or browser cannot correctly interpret the url / id. But you should use the wicket-portlet 1.5.1 version, as the previous versions have IDs for all tags. thats why i suggested to disable the MarkupIdPrepender, because then you shoul dhave the same IDs as without the portlet container. The only differences will be in the URLs. Also check if there is the same problem using any browser (I would test it f.e. on firefox first with firebug plugin enabled, that you see all the errors and unloaded libraries).
        Hide
        Martin Grigorov added a comment -

        bind() method sets the context for the execution of the bound function.
        I.e. aFunc.bind(

        {name: 'value'}

        ) will execute function 'aFunc' with ''this' set to the specified object

        {name : 'value'}

        .

        Show
        Martin Grigorov added a comment - bind() method sets the context for the execution of the bound function. I.e. aFunc.bind( {name: 'value'} ) will execute function 'aFunc' with ''this' set to the specified object {name : 'value'} .
        Hide
        Ronny Pscheidl added a comment -

        i have found the reason why precondition function is undefined.

        }.bind(this) cause this in function doGet. if i hide bind(this) it works well.

        what does bind(this) do? encoding problem or length of tag?

        there are screenshots which show with bind(this) and without.

        Show
        Ronny Pscheidl added a comment - i have found the reason why precondition function is undefined. }.bind(this) cause this in function doGet. if i hide bind(this) it works well. what does bind(this) do? encoding problem or length of tag? there are screenshots which show with bind(this) and without.
        Hide
        Thijs Vonk added a comment -

        I'm not on 1.5. And won't be for the forceable future (next 5-6months). I can check if this is 1.4 as wel. However I could only replay it on a live server for some reason. So I might not be able to help you.

        Just wanted to share my experience with the precondition problem. I never actually found the cause, only this solution that seemed to work.

        Show
        Thijs Vonk added a comment - I'm not on 1.5. And won't be for the forceable future (next 5-6months). I can check if this is 1.4 as wel. However I could only replay it on a live server for some reason. So I might not be able to help you. Just wanted to share my experience with the precondition problem. I never actually found the cause, only this solution that seemed to work.
        Hide
        Peter Pastrnak added a comment -

        about the precondition. try to disable MarkupIdPrepender in PortletFilter.java to check if it helps. you just have to comment out the following line:

        this.application.getComponentInitializationListeners().add(new MarkupIdPrepender());

        im just thinking if it could be the length of the ID or some character / sequence in it, that make Wicket.$() to return the undefined value.

        Show
        Peter Pastrnak added a comment - about the precondition. try to disable MarkupIdPrepender in PortletFilter.java to check if it helps. you just have to comment out the following line: this.application.getComponentInitializationListeners().add(new MarkupIdPrepender()); im just thinking if it could be the length of the ID or some character / sequence in it, that make Wicket.$() to return the undefined value.
        Hide
        Thijs Vonk added a comment - - edited

        We also had an issue with the precondition, esp in IE. This is in Liferay 5.3.2.
        I can't remember what version of IE, but I suspect IE9 as it was then the new kid. I looked up my svn change from then.
        We had an issue with the LazyLoadingPanel. So I created my own and ended up doing the following:

        +
        + @Override
        + protected CharSequence getPreconditionScript()
        +

        { + return "return true"; + }

        Never had a problem since.

        Show
        Thijs Vonk added a comment - - edited We also had an issue with the precondition, esp in IE. This is in Liferay 5.3.2. I can't remember what version of IE, but I suspect IE9 as it was then the new kid. I looked up my svn change from then. We had an issue with the LazyLoadingPanel. So I created my own and ended up doing the following: + + @Override + protected CharSequence getPreconditionScript() + { + return "return true"; + } Never had a problem since.
        Hide
        Peter Pastrnak added a comment -

        that wont solve it, as 'wicket-core' will use the WebRequest.isAjax(). check if it is already wrong in the http request or just gatein (or something else) does not preserve the case. otherwise you have to change f.e. the PortletServletRequestWrapper.java to make calls getHeader, getHeaderNames, getIntHeader, etc. case insensitive.

        Show
        Peter Pastrnak added a comment - that wont solve it, as 'wicket-core' will use the WebRequest.isAjax(). check if it is already wrong in the http request or just gatein (or something else) does not preserve the case. otherwise you have to change f.e. the PortletServletRequestWrapper.java to make calls getHeader, getHeaderNames, getIntHeader, etc. case insensitive.
        Hide
        Ronny Pscheidl added a comment -

        i will test other ajax components

        but i have found another problem within gatein. the header param "Wicket-Ajax" is lowercase. i have update ThreadPortletContext like this:

        public static boolean isAjax()

        { // GateIn header-param is served in lowercase values. return Strings.isTrue(((WebRequest)ThreadContext.getRequestCycle().getRequest()).getHeader(WebRequest.PARAM_AJAX)) || ((WebRequest) ThreadContext.getRequestCycle().getRequest()).isAjax(); }
        Show
        Ronny Pscheidl added a comment - i will test other ajax components but i have found another problem within gatein. the header param "Wicket-Ajax" is lowercase. i have update ThreadPortletContext like this: public static boolean isAjax() { // GateIn header-param is served in lowercase values. return Strings.isTrue(((WebRequest)ThreadContext.getRequestCycle().getRequest()).getHeader(WebRequest.PARAM_AJAX)) || ((WebRequest) ThreadContext.getRequestCycle().getRequest()).isAjax(); }
        Hide
        Peter Pastrnak added a comment -

        is it problem for every Ajax based component? I've tried to compare one of our 'orderBy' elements with yours but I could not find any difference. The ID of the element is, in my opinion, defined correctly and is the same as the one in Wicket.$(). Were all the Wicket Javascript libraries loaded correctly in your case (I guess they are, if it works) ?

        /poc-portlet/projectList/ps:NDI3NjI1OWQtYjE5OC00YmU2LTk1ODUtYWI1ZTFiOTU3MjVi/wicket/resource/org.apache.wicket.markup.html.WicketEventReference/wicket-event-ver-1316958366000.js"
        /poc-portlet/projectList/ps:NDI3NjI1OWQtYjE5OC00YmU2LTk1ODUtYWI1ZTFiOTU3MjVi/wicket/resource/org.apache.wicket.ajax.WicketAjaxReference/wicket-ajax-ver-1316958366000.js"
        /poc-portlet/projectList/ps:NDI3NjI1OWQtYjE5OC00YmU2LTk1ODUtYWI1ZTFiOTU3MjVi/wicket/resource/org.apache.wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug-ver-1316958366000.js"

        YOUR 'orderBy' component:

        <a
        href="/rpo/public/edp/applications/wicket?portal:componentId=4276259d-b198-4be6-9585-ab5e1b95725b&portal:type=action&interactionstate=JBPNS_rO0ABXdvAANfd3UAAAABAFsvcHJvamVjdExpc3QvPzM3LTEuSUxpbmtMaXN0ZW5lci10YWJsZS10b3BUb29sYmFycy10b29sYmFycy0yOC1oZWFkZXJzLTItaGVhZGVyLW9yZGVyQnlMaW5rAAdfX0VPRl9f"
        wicket:id="orderByLink"
        id="G4276259d_2db198_2d4be6_2d9585_2dab5e1b95725b_orderByLinkc0b2"
        class="wicket_orderUp"
        onclick="var wcall=wicketAjaxGet(
        '/rpo/public/edp/applications/wicket?portal:componentId=4276259d-b198-4be6-9585-ab5e1b95725b&portal:type=resource&portal:resourceID=/projectList/?37-1.IBehaviorListener.1-table-topToolbars-toolbars-28-headers-2-header-orderByLink&portal:cacheLevel=PAGE&portal:windowState=normal&portal:portletMode=view',
        function() { }.bind(this),function() { }.bind(this),
        function()

        { return Wicket.$('G4276259d_2db198_2d4be6_2d9585_2dab5e1b95725b_orderByLinkc0b2') != null; }

        .bind(this)
        );
        return !wcall;"
        >

        OUR 'orderBy' component:

        <a
        href="/portal/ecare/-/wellcome?p_auth=jfam95sK&p_p_id=EcareWelcomePortlet_WAR_ecareportlet&p_p_lifecycle=1&p_p_state=normal&p_p_mode=view&p_p_col_id=column-3&p_p_col_count=1&EcareWelcomePortlet_WAR_ecareportlet_wu=%2FEcareWelcomePortlet%2F%3F3-1.ILinkListener-welcomeContainer-invoiceComponent-content-head~id-sortBy~id"
        title=""
        class="tablebuton_up tablebuton_up"
        wicket:id="sortBy-id"
        id="EcareWelcomePortlet_WAR_ecareportlet_sortBy_id5b"
        onclick="var wcall=wicketAjaxGet(
        '/portal/ecare/-/wellcome?p_p_id=EcareWelcomePortlet_WAR_ecareportlet&p_p_lifecycle=2&p_p_state=normal&p_p_mode=view&p_p_resource_id=%2FEcareWelcomePortlet%2F%3F3-1.IBehaviorListener.1-welcomeContainer-invoiceComponent-content-head~id-sortBy~id&p_p_cacheability=cacheLevelPage&p_p_col_id=column-3&p_p_col_count=1',
        function() { }.bind(this),
        function() { }.bind(this),
        function()

        { return Wicket.$('_EcareWelcomePortlet_WAR_ecareportlet__sortBy_id5b') != null; }

        .bind(this)
        );
        return !wcall;"
        >

        Show
        Peter Pastrnak added a comment - is it problem for every Ajax based component? I've tried to compare one of our 'orderBy' elements with yours but I could not find any difference. The ID of the element is, in my opinion, defined correctly and is the same as the one in Wicket.$(). Were all the Wicket Javascript libraries loaded correctly in your case (I guess they are, if it works) ? /poc-portlet/projectList/ps:NDI3NjI1OWQtYjE5OC00YmU2LTk1ODUtYWI1ZTFiOTU3MjVi/wicket/resource/org.apache.wicket.markup.html.WicketEventReference/wicket-event-ver-1316958366000.js" /poc-portlet/projectList/ps:NDI3NjI1OWQtYjE5OC00YmU2LTk1ODUtYWI1ZTFiOTU3MjVi/wicket/resource/org.apache.wicket.ajax.WicketAjaxReference/wicket-ajax-ver-1316958366000.js" /poc-portlet/projectList/ps:NDI3NjI1OWQtYjE5OC00YmU2LTk1ODUtYWI1ZTFiOTU3MjVi/wicket/resource/org.apache.wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug-ver-1316958366000.js" YOUR 'orderBy' component: <a href="/rpo/public/edp/applications/wicket?portal:componentId=4276259d-b198-4be6-9585-ab5e1b95725b&portal:type=action&interactionstate=JBPNS_rO0ABXdvAANfd3UAAAABAFsvcHJvamVjdExpc3QvPzM3LTEuSUxpbmtMaXN0ZW5lci10YWJsZS10b3BUb29sYmFycy10b29sYmFycy0yOC1oZWFkZXJzLTItaGVhZGVyLW9yZGVyQnlMaW5rAAdfX0VPRl9f" wicket:id="orderByLink" id="G4276259d_2db198_2d4be6_2d9585_2dab5e1b95725b_orderByLinkc0b2" class="wicket_orderUp" onclick="var wcall=wicketAjaxGet( '/rpo/public/edp/applications/wicket?portal:componentId=4276259d-b198-4be6-9585-ab5e1b95725b&portal:type=resource&portal:resourceID=/projectList/?37-1.IBehaviorListener.1-table-topToolbars-toolbars-28-headers-2-header-orderByLink&portal:cacheLevel=PAGE&portal:windowState=normal&portal:portletMode=view', function() { }.bind(this),function() { }.bind(this), function() { return Wicket.$('G4276259d_2db198_2d4be6_2d9585_2dab5e1b95725b_orderByLinkc0b2') != null; } .bind(this) ); return !wcall;" > OUR 'orderBy' component: <a href="/portal/ecare/-/wellcome?p_auth=jfam95sK&p_p_id=EcareWelcomePortlet_WAR_ecareportlet&p_p_lifecycle=1&p_p_state=normal&p_p_mode=view&p_p_col_id=column-3&p_p_col_count=1& EcareWelcomePortlet_WAR_ecareportlet _wu=%2FEcareWelcomePortlet%2F%3F3-1.ILinkListener-welcomeContainer-invoiceComponent-content-head~id-sortBy~id" title="" class="tablebuton_up tablebuton_up" wicket:id="sortBy-id" id=" EcareWelcomePortlet_WAR_ecareportlet _sortBy_id5b" onclick="var wcall=wicketAjaxGet( '/portal/ecare/-/wellcome?p_p_id=EcareWelcomePortlet_WAR_ecareportlet&p_p_lifecycle=2&p_p_state=normal&p_p_mode=view&p_p_resource_id=%2FEcareWelcomePortlet%2F%3F3-1.IBehaviorListener.1-welcomeContainer-invoiceComponent-content-head~id-sortBy~id&p_p_cacheability=cacheLevelPage&p_p_col_id=column-3&p_p_col_count=1', function() { }.bind(this), function() { }.bind(this), function() { return Wicket.$('_EcareWelcomePortlet_WAR_ecareportlet__sortBy_id5b') != null; } .bind(this) ); return !wcall;" >
        Hide
        Ronny Pscheidl added a comment -

        i have tried both. the attached page is generated by 1.5.0.

        Show
        Ronny Pscheidl added a comment - i have tried both. the attached page is generated by 1.5.0.
        Hide
        Peter Pastrnak added a comment -

        which version of wicket-portlet are you using? (1.5.1?) can you attach the generated html, pls.?

        Show
        Peter Pastrnak added a comment - which version of wicket-portlet are you using? (1.5.1?) can you attach the generated html, pls.?
        Hide
        Ronny Pscheidl added a comment -

        your right. but i'm new to wicket an i don't know how wicket-ajax is working, so i hope i to get some support.

        url and id are correct. the precondition will first be set to call.request.precondition = precondition; but in the function doGet: function() { if (this.precondition()) it is undefined. without portal context it is not undefined and returns true.

        Show
        Ronny Pscheidl added a comment - your right. but i'm new to wicket an i don't know how wicket-ajax is working, so i hope i to get some support. url and id are correct. the precondition will first be set to call.request.precondition = precondition; but in the function doGet: function() { if (this.precondition()) it is undefined. without portal context it is not undefined and returns true.
        Hide
        Peter Pastrnak added a comment -

        I don't think, that modifying the http response with 'wicket-ajax.js' is the solution. You could change this directly in the wicket-ajax.js, if its really a bug in the javascript library (most probably it's not)... Question is, why did the precondition check fail... (e.g. if some URL or ID was generated incorrectly,...)

        Show
        Peter Pastrnak added a comment - I don't think, that modifying the http response with 'wicket-ajax.js' is the solution. You could change this directly in the wicket-ajax.js, if its really a bug in the javascript library (most probably it's not)... Question is, why did the precondition check fail... (e.g. if some URL or ID was generated incorrectly,...)
        Hide
        Ronny Pscheidl added a comment - - edited

        Hello together,
        im working with GateIn. Ajax request didn't work. I get the message: Ajax GET stopped because of precondition check, url...

        The reason is that the following part in wicket-ajax.js returns undefiened:
        // The actual get request implementation
        doGet: function() {
        if (this.precondition()) {

        For testing i have patched ReponseState like this:

        // FIX von Ronny für GateIn
        String output = new String(charOutputBuffer.getBuffer());
        output = output.replaceAll(Pattern.quote("function() {return Wicket.$("), Matcher.quoteReplacement("null /*function()

        {return Wicket.$(")); output = output.replaceAll(Pattern.quote(") != null;}

        .bind(this));return !wcall;"), Matcher.quoteReplacement(") != null;}.bind(this)*/);return !wcall;"));

        if precondition is null then precondition always return true.

        Can you tell me where the right position is to fix this?

        Kind Regards
        Ronny

        excuse my bad english )

        Show
        Ronny Pscheidl added a comment - - edited Hello together, im working with GateIn. Ajax request didn't work. I get the message: Ajax GET stopped because of precondition check, url... The reason is that the following part in wicket-ajax.js returns undefiened: // The actual get request implementation doGet: function() { if (this.precondition()) { For testing i have patched ReponseState like this: // FIX von Ronny für GateIn String output = new String(charOutputBuffer.getBuffer()); output = output.replaceAll(Pattern.quote("function() {return Wicket.$("), Matcher.quoteReplacement("null /*function() {return Wicket.$(")); output = output.replaceAll(Pattern.quote(") != null;} .bind(this));return !wcall;"), Matcher.quoteReplacement(") != null;}.bind(this)*/);return !wcall;")); if precondition is null then precondition always return true. Can you tell me where the right position is to fix this? Kind Regards Ronny excuse my bad english )
        Hide
        Peter Pastrnak added a comment -

        Bug fix: Markup ID was generated for all components (as setMarkupId calls also setOurputMarkupId(true)).
        I have also added a patched wicket-request UrlRenderer (for Liferay users).

        Show
        Peter Pastrnak added a comment - Bug fix: Markup ID was generated for all components (as setMarkupId calls also setOurputMarkupId(true)). I have also added a patched wicket-request UrlRenderer (for Liferay users).
        Hide
        Peter Pastrnak added a comment -

        Added support for shared resource URLs (similar to the old one in Wicket 1.4, just different portlet window ID encoding). I'm not sure what resources should have a shared URL, so I chose all served by a SharedResourceReference and all PackageResources.
        Now it should serve files like wicket-event.js or wicket-ajax.js directly by the WicketFilter (avoiding the portlet container).

        Show
        Peter Pastrnak added a comment - Added support for shared resource URLs (similar to the old one in Wicket 1.4, just different portlet window ID encoding). I'm not sure what resources should have a shared URL, so I chose all served by a SharedResourceReference and all PackageResources. Now it should serve files like wicket-event.js or wicket-ajax.js directly by the WicketFilter (avoiding the portlet container).
        Hide
        Peter Pastrnak added a comment -

        Currently seems to be impossible for me to reserve more time for this. The earliest I could find some time for test cases is in December. If we find some bugs while developing our projects, I can submit patches, but currently not more.
        From what I remember, there are most probably some parts, that are not necessary anymore (they were there because of Wicket 1.4 compatibility with older versions), but I left them there, as I didn't have enough time to investigate why were they there and if they can be safely removed. Also in WicketFilter there is a 'hack' to access the application object, as I could not find a way how to get to it. Hopefully I did not remove too much of the old bridge and it will work on other portlet containers too. We use only Liferay. Don't forget, that it won't work for other people using Liferay, if you don't 'fix' the UrlRenderer issue. I haven't submitted a bug report to them yet, as it would be good to test it with a newer version of Liferay first.

        Show
        Peter Pastrnak added a comment - Currently seems to be impossible for me to reserve more time for this. The earliest I could find some time for test cases is in December. If we find some bugs while developing our projects, I can submit patches, but currently not more. From what I remember, there are most probably some parts, that are not necessary anymore (they were there because of Wicket 1.4 compatibility with older versions), but I left them there, as I didn't have enough time to investigate why were they there and if they can be safely removed. Also in WicketFilter there is a 'hack' to access the application object, as I could not find a way how to get to it. Hopefully I did not remove too much of the old bridge and it will work on other portlet containers too. We use only Liferay. Don't forget, that it won't work for other people using Liferay, if you don't 'fix' the UrlRenderer issue. I haven't submitted a bug report to them yet, as it would be good to test it with a newer version of Liferay first.
        Hide
        Martin Grigorov added a comment -

        As I can see there are no monkey-patched classes from Wicket distro so these classes can be packed in WicketStuff project.
        There were some people asking for Portlet support in 1.5 so they will have a chance to play with this project while re-incubating in WicketStuff.

        Before merging them back as wicket-portlet sub-module in Apache Wicket I'd like to have some tests. Preferably integration tests like the ones in wicket-examples - start Portlet container (Pluto?!), fire some requests, assert the responses.

        Show
        Martin Grigorov added a comment - As I can see there are no monkey-patched classes from Wicket distro so these classes can be packed in WicketStuff project. There were some people asking for Portlet support in 1.5 so they will have a chance to play with this project while re-incubating in WicketStuff. Before merging them back as wicket-portlet sub-module in Apache Wicket I'd like to have some tests. Preferably integration tests like the ones in wicket-examples - start Portlet container (Pluto?!), fire some requests, assert the responses.
        Hide
        Peter Pastrnak added a comment -

        I have attached the modified portlet bridge, that works with Wicket 1.5.RC7. For Liferay the only problem we found was the one in the UrlEncoder. Portlet applications have to use the 'org.apache.wicket.portlet.PortletFilter' and 'org.apache.wicket.portlet.WicketPortlet'.

        Show
        Peter Pastrnak added a comment - I have attached the modified portlet bridge, that works with Wicket 1.5.RC7. For Liferay the only problem we found was the one in the UrlEncoder. Portlet applications have to use the 'org.apache.wicket.portlet.PortletFilter' and 'org.apache.wicket.portlet.WicketPortlet'.
        Hide
        Peter Pastrnak added a comment -

        Portlet bridge that works with Wicket 1.5.RC7.

        Show
        Peter Pastrnak added a comment - Portlet bridge that works with Wicket 1.5.RC7.
        Hide
        Peter Pastrnak added a comment - - edited

        yes, but we would like to finish tests on one of our bigger projects first. this should take about 2 weeks. afterwards I can write what are differences between the old and the new version, that I know about. Because currently I f.e. removed the possibility to have shared resources, that are accessed directly, avoiding the portlet container. This behaviour was not desirable for us, as these are portlet resources, so we need to have them and their urls to be controlled by the portlet container. this type of urls used to be generated for all 'ISharedResourceRequestTarget'...

        Show
        Peter Pastrnak added a comment - - edited yes, but we would like to finish tests on one of our bigger projects first. this should take about 2 weeks. afterwards I can write what are differences between the old and the new version, that I know about. Because currently I f.e. removed the possibility to have shared resources, that are accessed directly, avoiding the portlet container. This behaviour was not desirable for us, as these are portlet resources, so we need to have them and their urls to be controlled by the portlet container. this type of urls used to be generated for all 'ISharedResourceRequestTarget'...
        Hide
        Igor Vaynberg added a comment -

        are you going to share the code with us so we can consider putting it back into core?

        Show
        Igor Vaynberg added a comment - are you going to share the code with us so we can consider putting it back into core?
        Hide
        Peter Pastrnak added a comment -

        The old one uses the "IRequestCodingStrategy", that works with pure String instead of the Url type. I had just about 3 days to make the old one running on Wicket 1.5 and I could not find anything like RequestCodingStrategy, so I created a custom RequestMapper, that wraps the SystemMapper and modifies the URL depending on the RequestHandler. Its maybe not the best solution, but that was the only one I could find within very short time. Now its completely separated from wicket-core, you just have to subtype PortletApplication instead of WebApplication to let it initialize the request mapper, render strategy and a component initialization listener (to adapt the markup ids).

        Show
        Peter Pastrnak added a comment - The old one uses the "IRequestCodingStrategy", that works with pure String instead of the Url type. I had just about 3 days to make the old one running on Wicket 1.5 and I could not find anything like RequestCodingStrategy, so I created a custom RequestMapper, that wraps the SystemMapper and modifies the URL depending on the RequestHandler. Its maybe not the best solution, but that was the only one I could find within very short time. Now its completely separated from wicket-core, you just have to subtype PortletApplication instead of WebApplication to let it initialize the request mapper, render strategy and a component initialization listener (to adapt the markup ids).
        Hide
        Martin Grigorov added a comment -

        The behavior is the same in Wicket 1.4 (see WicketUrlEncoder).
        How portlets support works there ?

        Show
        Martin Grigorov added a comment - The behavior is the same in Wicket 1.4 (see WicketUrlEncoder). How portlets support works there ?
        Hide
        Peter Pastrnak added a comment -

        Any plans to add support for the legacy systems? (e.g. by allowing to set a flag on the Url)
        At least Liferay versions prior to 6.0.5 behave as a legacy system. I havent checked newer ones, as an upgrade is currently not an option for us.

        Show
        Peter Pastrnak added a comment - Any plans to add support for the legacy systems? (e.g. by allowing to set a flag on the Url) At least Liferay versions prior to 6.0.5 behave as a legacy system. I havent checked newer ones, as an upgrade is currently not an option for us.
        Hide
        Martin Grigorov added a comment -

        http://www.ietf.org/rfc/rfc3986.txt , point 3.4 says that '?' and '/' can be used in the query string. Only the legacy systems cannot deal with it.
        The same spec also at http://labs.apache.org/webarch/uri/rfc/rfc3986.html#query

        Show
        Martin Grigorov added a comment - http://www.ietf.org/rfc/rfc3986.txt , point 3.4 says that '?' and '/' can be used in the query string. Only the legacy systems cannot deal with it. The same spec also at http://labs.apache.org/webarch/uri/rfc/rfc3986.html#query

          People

          • Assignee:
            Unassigned
            Reporter:
            Peter Pastrnak
          • Votes:
            9 Vote for this issue
            Watchers:
            13 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development