found fusion/pluto interaction bug
Hi all, this mail should be of particular interest for David and Ate. A few days ago I posted msg15905.html entitled Something weird happening with fusion/pluto. In fact the navigational state IS the cause of the problem. I'd like to have your opinion about how to workaround this as several solutions are possible. Before explaining the solutions, here is the problem : When you want to set the action of a form or have a link calling a portlet action you must use either a portlet:actionURL or use response.createActiontURL() method. This in turns calls the PathInfoEncodingPortalURL which extends AbstractPortalURL. This implementation of AbstractPortalURL adds a _ns:xxx element ni the request URL just after contextPath+servletPath (this is for example /jetspeed/portal/) and then appends the rest of the original request. This gives something like this : /jetspeed/portal/_ns:xx/media-type/html/user/admin/page/new.psml/js_peid/PXXX BUT the problem is that turbine reads the URL to get its parameter hashmap ready this way : first element after context path + servlet path is meant to be parameter name, and then URL is supposed to be constructed as an alternance between paramter names and parameters values. This means that if you have such a (normal jetspeed)URL : /jetspeed/portal/media-type/html/user/admin/page/new.psml/js_peid/PXXX the resulting hashmap will be : { media-type=html user=admin page=news.psml js_peid=PXXX } but it the case of the URL returned by pluto, eveything is mixed up because first element is navigational state which is not what turbine expects and has nothing to do with a key value pair. This leads to such a hashmap : { _ns:xx=media-type html=user admin=page js_peid=news.psml PXX= } and of course when jetspeed wants to get the profile, it uses the parameters found in runData object and searches for the page parameter which it doesn't find. Jetspeed then constructs a default profile, pointing to default.psml page. And this is why when you click on an action button in a JSR168 portlet contained in a PSML page which is NOT default.psml you get redirected to default.psml page (which is of course not what we want). Now possible solutions are : - rewrite DefaultJetspeedParameterParser and override setRequest method so that it ignores the _ns:XXX element in URL (if it exists) and begins parsing right after. This is not very elegant and is clearly a workaround - Maybe configure pluto to use QueryStringEncodingPortalURL implementation of AbstractPortletURL so that ns is put as a paramter in the URL. But I would know how this is done in JSFusion and I don't know if jetspeed will be happy with this knew and unknown parameter. Question is : Ate and David what do you think about the best way to circumvent this? Do you think it's possible to tell pluto not to add the ns element at all ? Thanks for your help Fabrice - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: found fusion/pluto interaction bug
Fabrice, First of all, thanks for diving into this problem. I try to answer below but bear in mind I'm doing it just from the head as my laptop crashed this morning and I'm in the middle of trying to recover from it what I can... Fabrice Dewasmes said: Hi all, this mail should be of particular interest for David and Ate. A few days ago I posted msg15905.html entitled Something weird happening with fusion/pluto. In fact the navigational state IS the cause of the problem. I'd like to have your opinion about how to workaround this as several solutions are possible. Before explaining the solutions, here is the problem : When you want to set the action of a form or have a link calling a portlet action you must use either a portlet:actionURL or use response.createActiontURL() method. This in turns calls the PathInfoEncodingPortalURL which extends AbstractPortalURL. This implementation of AbstractPortalURL adds a _ns:xxx element ni the request URL just after contextPath+servletPath (this is for example /jetspeed/portal/) and then appends the rest of the original request. This gives something like this : /jetspeed/portal/_ns:xx/media-type/html/user/admin/page/new.psml/js_peid/PXXX BUT the problem is that turbine reads the URL to get its parameter hashmap ready this way : first element after context path + servlet path is meant to be parameter name, and then URL is supposed to be constructed as an alternance between paramter names and parameters values. This means that if you have such a (normal jetspeed)URL : /jetspeed/portal/media-type/html/user/admin/page/new.psml/js_peid/PXXX the resulting hashmap will be : { media-type=html user=admin page=news.psml js_peid=PXXX } but it the case of the URL returned by pluto, eveything is mixed up because first element is navigational state which is not what turbine expects and has nothing to do with a key value pair. This leads to such a hashmap : { _ns:xx=media-type html=user admin=page js_peid=news.psml PXX= } and of course when jetspeed wants to get the profile, it uses the parameters found in runData object and searches for the page parameter which it doesn't find. Jetspeed then constructs a default profile, pointing to default.psml page. And this is why when you click on an action button in a JSR168 portlet contained in a PSML page which is NOT default.psml you get redirected to default.psml page (which is of course not what we want). Now possible solutions are : - rewrite DefaultJetspeedParameterParser and override setRequest method so that it ignores the _ns:XXX element in URL (if it exists) and begins parsing right after. This is not very elegant and is clearly a workaround - Maybe configure pluto to use QueryStringEncodingPortalURL implementation of AbstractPortletURL so that ns is put as a paramter in the URL. But I would know how this is done in JSFusion and I don't know if jetspeed will be happy with this knew and unknown parameter. I think for just testing out your solution, the last option is the easiest and quickest to realize and test (in the end, the first might be the better solution or maybe even another, but for that I'll have to investigate this first). Using the QueryStringEncodingPortalURL is configured against Jetspeed, not Pluto. You should be able to do so in the jetspeed-spring.xml under WEB-INF/assembly. Lookup the NavigationalStateComponent bean definition. One of the constructor arguments (I think the second) defined the PortalURL implementation to use. Just try it out. If it solves your problem we will try to define the real solution after that. Regards, Ate Question is : Ate and David what do you think about the best way to circumvent this? Do you think it's possible to tell pluto not to add the ns element at all ? Thanks for your help Fabrice - 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]
Re: found fusion/pluto interaction bug
Hi, I think for just testing out your solution, the last option is the easiest and quickest to realize and test (in the end, the first might be the better solution or maybe even another, but for that I'll have to investigate this first). Using the QueryStringEncodingPortalURL is configured against Jetspeed, not Pluto. You should be able to do so in the jetspeed-spring.xml under WEB-INF/assembly. Lookup the NavigationalStateComponent bean definition. One of the constructor arguments (I think the second) defined the PortalURL implementation to use. yes I found this parameter just after having sent my email. Just try it out. If it solves your problem we will try to define the real solution after that. Changing navaigational state component strategy works like a charm. The only thing I'm unsure is (but I will have to double check QueryStringEncodingPortalURL) how this class handles previously existing parameter in the URL: are they preserved ? Anyway, maybe that we should look for a better way to circumvent the problem. What's your opinion ? regards Fabrice Regards, Ate Question is : Ate and David what do you think about the best way to circumvent this? Do you think it's possible to tell pluto not to add the ns element at all ? Thanks for your help Fabrice - 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] -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: Re: found fusion/pluto interaction bug]
Sorry, didn't notice at first I responded to Fabrice directly and not to the list. Original Message Subject: Re: found fusion/pluto interaction bug From:Ate Douma [EMAIL PROTECTED] Date:Tue, April 12, 2005 17:44 To: Fabrice Dewasmes [EMAIL PROTECTED] -- Fabrice Dewasmes said: Hi, I think for just testing out your solution, the last option is the easiest and quickest to realize and test (in the end, the first might be the better solution or maybe even another, but for that I'll have to investigate this first). Using the QueryStringEncodingPortalURL is configured against Jetspeed, not Pluto. You should be able to do so in the jetspeed-spring.xml under WEB-INF/assembly. Lookup the NavigationalStateComponent bean definition. One of the constructor arguments (I think the second) defined the PortalURL implementation to use. yes I found this parameter just after having sent my email. Just try it out. If it solves your problem we will try to define the real solution after that. Changing navaigational state component strategy works like a charm. Great! The only thing I'm unsure is (but I will have to double check QueryStringEncodingPortalURL) how this class handles previously existing parameter in the URL: are they preserved ? Yes. No difference there. Anyway, maybe that we should look for a better way to circumvent the problem. I agree. What's your opinion ? I don't have any at the moment. I would need time to investigate this more, but I won't have time for that before the end of this week. I expect that David will be able to give a better response (if he reads the mailing list today, I know he too is covered in work till at least Thursday). Regards, Ate regards Fabrice Regards, Ate Question is : Ate and David what do you think about the best way to circumvent this? Do you think it's possible to tell pluto not to add the ns element at all ? Thanks for your help Fabrice - 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] -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Re: found fusion/pluto interaction bug]
I was planning on release 1.6 today and getting it over with. I'll look into once I get started here. join me out on irc if you get a chance (i'll be starting here in 30 min or so) how bad is the hard drive situation? Ate Douma wrote: Sorry, didn't notice at first I responded to Fabrice directly and not to the list. Original Message Subject: Re: found fusion/pluto interaction bug From:Ate Douma [EMAIL PROTECTED] Date:Tue, April 12, 2005 17:44 To: Fabrice Dewasmes [EMAIL PROTECTED] -- Fabrice Dewasmes said: Hi, I think for just testing out your solution, the last option is the easiest and quickest to realize and test (in the end, the first might be the better solution or maybe even another, but for that I'll have to investigate this first). Using the QueryStringEncodingPortalURL is configured against Jetspeed, not Pluto. You should be able to do so in the jetspeed-spring.xml under WEB-INF/assembly. Lookup the NavigationalStateComponent bean definition. One of the constructor arguments (I think the second) defined the PortalURL implementation to use. yes I found this parameter just after having sent my email. Just try it out. If it solves your problem we will try to define the real solution after that. Changing navaigational state component strategy works like a charm. Great! The only thing I'm unsure is (but I will have to double check QueryStringEncodingPortalURL) how this class handles previously existing parameter in the URL: are they preserved ? Yes. No difference there. Anyway, maybe that we should look for a better way to circumvent the problem. I agree. What's your opinion ? I don't have any at the moment. I would need time to investigate this more, but I won't have time for that before the end of this week. I expect that David will be able to give a better response (if he reads the mailing list today, I know he too is covered in work till at least Thursday). Regards, Ate regards Fabrice Regards, Ate Question is : Ate and David what do you think about the best way to circumvent this? Do you think it's possible to tell pluto not to add the ns element at all ? Thanks for your help Fabrice - 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] -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] [office] +01 707 773-4646 [mobile] +01 707 529 9194 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: found fusion/pluto interaction bug
Fabrice Dewasmes wrote: Hi all, this mail should be of particular interest for David and Ate. A few days ago I posted msg15905.html entitled Something weird happening with fusion/pluto. In fact the navigational state IS the cause of the problem. I'd like to have your opinion about how to workaround this as several solutions are possible. Before explaining the solutions, here is the problem : When you want to set the action of a form or have a link calling a portlet action you must use either a portlet:actionURL or use response.createActiontURL() method. This in turns calls the PathInfoEncodingPortalURL which extends AbstractPortalURL. This implementation of AbstractPortalURL adds a _ns:xxx element ni the request URL just after contextPath+servletPath (this is for example /jetspeed/portal/) and then appends the rest of the original request. This gives something like this : /jetspeed/portal/_ns:xx/media-type/html/user/admin/page/new.psml/js_peid/PXXX BUT the problem is that turbine reads the URL to get its parameter hashmap ready this way : first element after context path + servlet path is meant to be parameter name, and then URL is supposed to be constructed as an alternance between paramter names and parameters values. This means that if you have such a (normal jetspeed)URL : /jetspeed/portal/media-type/html/user/admin/page/new.psml/js_peid/PXXX the resulting hashmap will be : { media-type=html user=admin page=news.psml js_peid=PXXX } but it the case of the URL returned by pluto, eveything is mixed up because first element is navigational state which is not what turbine expects and has nothing to do with a key value pair. This leads to such a hashmap : { _ns:xx=media-type html=user admin=page js_peid=news.psml PXX= } and of course when jetspeed wants to get the profile, it uses the parameters found in runData object and searches for the page parameter which it doesn't find. Jetspeed then constructs a default profile, pointing to default.psml page. And this is why when you click on an action button in a JSR168 portlet contained in a PSML page which is NOT default.psml you get redirected to default.psml page (which is of course not what we want). Now possible solutions are : - rewrite DefaultJetspeedParameterParser and override setRequest method so that it ignores the _ns:XXX element in URL (if it exists) and begins parsing right after. This is not very elegant and is clearly a workaround - Maybe configure pluto to use QueryStringEncodingPortalURL implementation of AbstractPortletURL so that ns is put as a paramter in the URL. But I would know how this is done in JSFusion and I don't know if jetspeed will be happy with this knew and unknown parameter. Question is : Ate and David what do you think about the best way to circumvent this? Do you think it's possible to tell pluto not to add the ns element at all ? I would personnally say that the best way would be to define a new FusionEncodingPortalURL that behaves just like PathInfoEncoding except that it adds the follwoing string : _ns/_ns: instead of simply _ns: It would change anything for j2 since it specically looks for '_ns:' as an identifier and will allow Turbine to recognize a new _ns parameter which it would care about but at least will not break the othher parts of the URL. The Fusion assembly script needs to use the FusionPortalURL instead of any of the regular ones. What do you think ? -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: found fusion/pluto interaction bug
Raphaël Luta wrote: I would personnally say that the best way would be to define a new FusionEncodingPortalURL that behaves just like PathInfoEncoding except that it adds the follwoing string : _ns/_ns: instead of simply _ns: It would change anything for j2 since it specically looks for '_ns:' as an identifier and will allow Turbine to recognize a new _ns parameter which it would care about but at least will not break the othher parts of the URL. The Fusion assembly script needs to use the FusionPortalURL instead of any of the regular ones. What do you think ? Looks Turbine friendly to me. Are you going to write it ? Im going to try releasing 1.6 today. If we could get the fix in now I'd be glad to incorporate it in the release -- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] [office] +01 707 773-4646 [mobile] +01 707 529 9194 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: found fusion/pluto interaction bug
David Sean Taylor wrote: Raphaël Luta wrote: I would personnally say that the best way would be to define a new FusionEncodingPortalURL that behaves just like PathInfoEncoding except that it adds the follwoing string : _ns/_ns: instead of simply _ns: It would change anything for j2 since it specically looks for '_ns:' as an identifier and will allow Turbine to recognize a new _ns parameter which it would care about but at least will not break the othher parts of the URL. The Fusion assembly script needs to use the FusionPortalURL instead of any of the regular ones. What do you think ? Looks Turbine friendly to me. Are you going to write it ? Im going to try releasing 1.6 today. I thought we would first go through Release candidates for 1.6 before announcing an official 1.6 release ? If we could get the fix in now I'd be glad to incorporate it in the release I can write it easily but I don't have currently the environment to test it :) I've not yet run Fusion... I'll commit a patch later this evening. -- Raphaël Luta - [EMAIL PROTECTED] Aptiwan, l'intelligence du réseau - http://www.aptiwan.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: found fusion/pluto interaction bug
Raphaël Luta wrote: David Sean Taylor wrote: Raphaël Luta wrote: I would personnally say that the best way would be to define a new FusionEncodingPortalURL that behaves just like PathInfoEncoding except that it adds the follwoing string : _ns/_ns: instead of simply _ns: It would change anything for j2 since it specically looks for '_ns:' as an identifier and will allow Turbine to recognize a new _ns parameter which it would care about but at least will not break the othher parts of the URL. The Fusion assembly script needs to use the FusionPortalURL instead of any of the regular ones. What do you think ? Looks Turbine friendly to me. Are you going to write it ? Im going to try releasing 1.6 today. I thought we would first go through Release candidates for 1.6 before announcing an official 1.6 release ? If we could get the fix in now I'd be glad to incorporate it in the release I can write it easily but I don't have currently the environment to test it :) I've not yet run Fusion... I'll commit a patch later this evening. anyway this is a good idea. I've got some time tomorrow to write and test it. I can submit something tomorrow at around 12:00. Is that OK for you ? Fabrice -- Fabrice Dewasmes Responsable du domaine urbanisation des systèmes d'information [EMAIL PROTECTED] 06.89.88.65.37 -- Open Wide 14 rue Gaillon 75002 PARIS www.openwide.fr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: found fusion/pluto interaction bug
Fabrice Dewasmes wrote: I can write it easily but I don't have currently the environment to test it :) I've not yet run Fusion... I'll commit a patch later this evening. anyway this is a good idea. I've got some time tomorrow to write and test it. I can submit something tomorrow at around 12:00. Is that OK for you ? Fabrice It's fixed in Jetspeed 2 CVS but you're welcome to test it out in Fusion. You'll have to update the Fusion assembly script to use FusionPathEncodingPortalURL instead of PathEncodingPortalURL and also move the dependencies to J2-M3-dev and build yourself the M3-dev artefact for it to work though. -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: found fusion/pluto interaction bug
Raphaël Luta wrote: Fabrice Dewasmes wrote: I can write it easily but I don't have currently the environment to test it :) I've not yet run Fusion... I'll commit a patch later this evening. anyway this is a good idea. I've got some time tomorrow to write and test it. I can submit something tomorrow at around 12:00. Is that OK for you ? Fabrice It's fixed in Jetspeed 2 CVS but you're welcome to test it out in Fusion. You'll have to update the Fusion assembly script to use FusionPathEncodingPortalURL instead of PathEncodingPortalURL and also move the dependencies to J2-M3-dev and build yourself the M3-dev artefact for it to work though. I've moved the patch to Jetspeed 1 Fusion CVS directly so you'll just need to cvs update and test it out if David can't complete the RC1 release today. -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]