You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-user@portals.apache.org by Fabrice Dewasmes <fa...@openwide.fr> on 2005/04/12 16:27:48 UTC
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:xxxxxx/media-type/html/user/admin/page/new.psml/js_peid/PXXXXXXX
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/PXXXXXXX
the resulting hashmap will be :
{
media-type=html
user=admin
page=news.psml
js_peid=PXXXXXXX
}
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:xxxxxx=media-type
html=user
admin=page
js_peid=news.psml
PXXXXXX=
}
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: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: found fusion/pluto interaction bug
Posted by David Sean Taylor <da...@bluesunrise.com>.
Raphaël Luta wrote:
>
> Let me know if I can do something now (or within the next 2 hours) else
> I'll at least test the cut release but probably not before Thursday.
>
Thursday sounds more realistic
Slim chance I'll finish anything today
Still working thru some issues here, for example the tutorial is broken
Just test it and fix anything you find
--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
[office] +01 707 773-4646
[mobile] +01 707 529 9194
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: found fusion/pluto interaction bug
Posted by Raphaël Luta <ra...@apache.org>.
David Sean Taylor wrote:
> Raphaël Luta wrote:
>
>> David Sean Taylor wrote:
>>
>>> Moved this to Jetspeed-dev
>>>
>>> Raphaël Luta wrote:
>>>
>>>>
>>>> I thought we would first go through Release candidates for 1.6
>>>> before announcing an official "1.6" release ?
>>>>
>>>
>>> im -1 on that because no one actually works on 1.6 anymore except myself
>>> There hasn't been any activity on the 1.6 branch for months
>>> My vote is to release it since I don't have the free tiem for a full
>>> RC cycle
>>>
>>
>> That's precisely why I think it's risky to call it a release directly.
>> If there's any bug found in the 1.6 release, we'll get a whole lot a
>> user queries on the list with few developers still actively working and
>> supporting the 1.x branch.
>> I'd like the 1.6 final release to be as stable as possible so that we
>> don't *have* to cut a 1.6.1 for maintenance reasons because of some
>> major issues in the release.
>> For me reaching this goal means cut a release, calling it RC1, freeze
>> the tree, ask all users to test it out for 2 weeks - 1 month and if no
>> one comes back with a showstopper or major bug, recut a 1.6 release
>> that can possibly be the same as 1.6 RC1 and publicly state that from
>> then
>> on Jetspeed 1 is in "maintenance mode" with no features added and that
>> all users should consider upgrading.
>>
>
> OK we can do this.
> Any help apprecated in making the release
>
> Today Ive come across a few things I'd like to fix in 1.6
> If I get them all fixed, then I'll try to release an RC1 late tonight
> Otherwise its ready when its ready...but definitely by the weekend
>
Let me know if I can do something now (or within the next 2 hours) else
I'll at least test the cut release but probably not before Thursday.
>>>
>>
>> I'm testing it in J2 right now... I'll ping you when it's done and
>> committed and let you update the Fusion assembly file, ok ?
>>
> Great!
>
--
Raphaël Luta - raphael@apache.org
Apache Portals - Enterprise Portal in Java
http://portals.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: found fusion/pluto interaction bug
Posted by Raphaël Luta <ra...@apache.org>.
Ate Douma wrote:
> Raphaël Luta said:
>
>>David Sean Taylor wrote:
>>
>>
>>>>I'm testing it in J2 right now... I'll ping you when it's done and
>>>>committed and let you update the Fusion assembly file, ok ?
>>>>
>>>
>>>Great!
>>>
>>
>>I've committed the patch in Jetspeed 2 but Fusion is built against
>>J2-M2... either we have to upgrade the the dependency to J2-HEAD
>>or generate a new J2-M3 artefact to build a proper dependency or
>>add a new dependency on a "patch" artefact that only contains the
>>FusionPathEncodingPortalURL class...
>>
>>I can't say I'm thrilled with any of these options :(
>
> Wouldn't it be easier to include the FusionPathEncodingPortalURL in J1
> under the Fusion subproject instead of adding it to J2?
> I'm not sure who would ever need a Turbine compatible solution when not
> using Fusion.
>
Probably a more sensible option, I just took the lazy way out and did
not change the package
I will create a org.apache.jetspeed.fusion.container.url.impl package
directly in fusion source and move out of J2 the code.
It's definitely cleaner this way.
--
Raphaël Luta - raphael@apache.org
Apache Portals - Enterprise Portal in Java
http://portals.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: found fusion/pluto interaction bug
Posted by Ate Douma <at...@douma.nu>.
Raphaël Luta said:
> David Sean Taylor wrote:
>
>>>
>>> I'm testing it in J2 right now... I'll ping you when it's done and
>>> committed and let you update the Fusion assembly file, ok ?
>>>
>> Great!
>>
>
> I've committed the patch in Jetspeed 2 but Fusion is built against
> J2-M2... either we have to upgrade the the dependency to J2-HEAD
> or generate a new J2-M3 artefact to build a proper dependency or
> add a new dependency on a "patch" artefact that only contains the
> FusionPathEncodingPortalURL class...
>
> I can't say I'm thrilled with any of these options :(
Wouldn't it be easier to include the FusionPathEncodingPortalURL in J1
under the Fusion subproject instead of adding it to J2?
I'm not sure who would ever need a Turbine compatible solution when not
using Fusion.
>
> --
> Raphaël Luta - raphael@apache.org
> Apache Portals - Enterprise Portal in Java
> http://portals.apache.org/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: found fusion/pluto interaction bug
Posted by Raphaël Luta <ra...@apache.org>.
David Sean Taylor wrote:
>>
>> I'm testing it in J2 right now... I'll ping you when it's done and
>> committed and let you update the Fusion assembly file, ok ?
>>
> Great!
>
I've committed the patch in Jetspeed 2 but Fusion is built against
J2-M2... either we have to upgrade the the dependency to J2-HEAD
or generate a new J2-M3 artefact to build a proper dependency or
add a new dependency on a "patch" artefact that only contains the
FusionPathEncodingPortalURL class...
I can't say I'm thrilled with any of these options :(
--
Raphaël Luta - raphael@apache.org
Apache Portals - Enterprise Portal in Java
http://portals.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: found fusion/pluto interaction bug
Posted by Raphaël Luta <ra...@apache.org>.
David Sean Taylor wrote:
>>>
>>
>> I'm testing it in J2 right now... I'll ping you when it's done and
>> committed and let you update the Fusion assembly file, ok ?
>>
> Great!
>
OK, moved the code the in J1 Fusion directly and updated the assembly
accordingly.
You can forget everything I've said about updating dependencies...
I just need to catch up some sleep and start thinking straight :/
--
Raphaël Luta - raphael@apache.org
Apache Portals - Enterprise Portal in Java
http://portals.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: found fusion/pluto interaction bug
Posted by David Sean Taylor <da...@bluesunrise.com>.
Raphaël Luta wrote:
> David Sean Taylor wrote:
>
>> Moved this to Jetspeed-dev
>>
>> Raphaël Luta wrote:
>>
>>>
>>> I thought we would first go through Release candidates for 1.6 before
>>> announcing an official "1.6" release ?
>>>
>>
>> im -1 on that because no one actually works on 1.6 anymore except myself
>> There hasn't been any activity on the 1.6 branch for months
>> My vote is to release it since I don't have the free tiem for a full
>> RC cycle
>>
>
> That's precisely why I think it's risky to call it a release directly.
> If there's any bug found in the 1.6 release, we'll get a whole lot a
> user queries on the list with few developers still actively working and
> supporting the 1.x branch.
> I'd like the 1.6 final release to be as stable as possible so that we
> don't *have* to cut a 1.6.1 for maintenance reasons because of some
> major issues in the release.
> For me reaching this goal means cut a release, calling it RC1, freeze
> the tree, ask all users to test it out for 2 weeks - 1 month and if no
> one comes back with a showstopper or major bug, recut a 1.6 release that
> can possibly be the same as 1.6 RC1 and publicly state that from then
> on Jetspeed 1 is in "maintenance mode" with no features added and that
> all users should consider upgrading.
>
OK we can do this.
Any help apprecated in making the release
Today Ive come across a few things I'd like to fix in 1.6
If I get them all fixed, then I'll try to release an RC1 late tonight
Otherwise its ready when its ready...but definitely by the weekend
>>
>
> I'm testing it in J2 right now... I'll ping you when it's done and
> committed and let you update the Fusion assembly file, ok ?
>
Great!
--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
[office] +01 707 773-4646
[mobile] +01 707 529 9194
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: found fusion/pluto interaction bug
Posted by Raphaël Luta <ra...@apache.org>.
David Sean Taylor wrote:
> Moved this to Jetspeed-dev
>
> Raphaël Luta wrote:
>
>>
>> I thought we would first go through Release candidates for 1.6 before
>> announcing an official "1.6" release ?
>>
>
> im -1 on that because no one actually works on 1.6 anymore except myself
> There hasn't been any activity on the 1.6 branch for months
> My vote is to release it since I don't have the free tiem for a full RC
> cycle
>
That's precisely why I think it's risky to call it a release directly.
If there's any bug found in the 1.6 release, we'll get a whole lot a
user queries on the list with few developers still actively working and
supporting the 1.x branch.
I'd like the 1.6 final release to be as stable as possible so that we
don't *have* to cut a 1.6.1 for maintenance reasons because of some
major issues in the release.
For me reaching this goal means cut a release, calling it RC1, freeze
the tree, ask all users to test it out for 2 weeks - 1 month and if no
one comes back with a showstopper or major bug, recut a 1.6 release that
can possibly be the same as 1.6 RC1 and publicly state that from then
on Jetspeed 1 is in "maintenance mode" with no features added and that
all users should consider upgrading.
>>> 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.
>>
> send me a patch and i'll test it immediately
>
I'm testing it in J2 right now... I'll ping you when it's done and
committed and let you update the Fusion assembly file, ok ?
--
Raphaël Luta - raphael@apache.org
Apache Portals - Enterprise Portal in Java
http://portals.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: found fusion/pluto interaction bug
Posted by David Sean Taylor <da...@bluesunrise.com>.
Moved this to Jetspeed-dev
Raphaël Luta wrote:
>
> I thought we would first go through Release candidates for 1.6 before
> announcing an official "1.6" release ?
>
im -1 on that because no one actually works on 1.6 anymore except myself
There hasn't been any activity on the 1.6 branch for months
My vote is to release it since I don't have the free tiem for a full RC
cycle
>> 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.
>
send me a patch and i'll test it immediately
--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
[office] +01 707 773-4646
[mobile] +01 707 529 9194
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: found fusion/pluto interaction bug
Posted by Raphaël Luta <ra...@apache.org>.
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 - raphael@apache.org
Apache Portals - Enterprise Portal in Java
http://portals.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: found fusion/pluto interaction bug
Posted by Raphaël Luta <ra...@apache.org>.
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 - raphael@apache.org
Apache Portals - Enterprise Portal in Java
http://portals.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: found fusion/pluto interaction bug
Posted by Fabrice Dewasmes <fa...@openwide.fr>.
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
fabrice.dewasmes@openwide.fr
06.89.88.65.37
--
Open Wide
14 rue Gaillon
75002 PARIS
www.openwide.fr
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: found fusion/pluto interaction bug
Posted by Raphaël Luta <ra...@aptiwan.com>.
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 - raphael.luta@aptiwan.com
Aptiwan, l'intelligence du réseau - http://www.aptiwan.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: found fusion/pluto interaction bug
Posted by David Sean Taylor <da...@bluesunrise.com>.
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
david@bluesunrise.com
[office] +01 707 773-4646
[mobile] +01 707 529 9194
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: found fusion/pluto interaction bug
Posted by Raphaël Luta <ra...@apache.org>.
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:xxxxxx/media-type/html/user/admin/page/new.psml/js_peid/PXXXXXXX
>
> 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/PXXXXXXX
>
> the resulting hashmap will be :
>
> {
> media-type=html
> user=admin
> page=news.psml
> js_peid=PXXXXXXX
> }
>
> 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:xxxxxx=media-type
> html=user
> admin=page
> js_peid=news.psml
> PXXXXXX=
> }
>
> 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 - raphael@apache.org
Apache Portals - Enterprise Portal in Java
http://portals.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: found fusion/pluto interaction bug
Posted by Fabrice Dewasmes <fa...@openwide.fr>.
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: jetspeed-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>
>
--
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: found fusion/pluto interaction bug
Posted by Ate Douma <at...@douma.nu>.
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:xxxxxx/media-type/html/user/admin/page/new.psml/js_peid/PXXXXXXX
>
> 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/PXXXXXXX
>
> the resulting hashmap will be :
>
> {
> media-type=html
> user=admin
> page=news.psml
> js_peid=PXXXXXXX
> }
>
> 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:xxxxxx=media-type
> html=user
> admin=page
> js_peid=news.psml
> PXXXXXX=
> }
>
> 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: jetspeed-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org