-
Type:
Bug
-
Status: Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: facesbridge-tck-3.0.0, facesbridge-tck-4.0.0
-
Fix Version/s: facesbridge-tck-3.1.0, facesbridge-tck-5.0.0, facesbridge-tck-6.0.0, facesbridge-tck-4.1.0
-
Component/s: FacesBridge TCK
-
Labels:None
The Bridge TCK assumes that the portlet container uses ampersand delimiters to separate URL parameters. This is indeed the way Liferay Portal (and to some extent with Pluto 2.x) works. But Portlet 3.0 made URL escaping requirements to be less restrictive in PORTLETSPEC3-69 which is why TestPage127 (encodeURLEscapingTest) fails in Pluto 3.0.
The test calls ExternalContext.encodeActionURL(String url) with the value "/com.liferay.faces.test.bridge.tck.main.portlet/tests/SingleRequestTest.jsf?parm1=a&param2=b"
In Pluto 2.0, the encoded URL contains ampersands as delimiters for name=value pairs, and strictly encodes them when BaseURL.write(String url, true) is called:
/pluto/portal/TestPage127/ __accom0x2liferay0x2faces0x2test0x2bridge0x2tck0x2main0x2portlet0x2chapter60x110x130x11Tests-encodeURLEscapingTest-portlet!471674933%7C0 ?_facesViewIdRender=%2Ftests%2FSingleRequestTest.jsf&param2=b&parm1=a
But Pluto 3.0 uses forward slashes to delimit name:value pairs and therefore does not need to strictly encode the result:
/pluto/portal/TestPage127/ __pdcom.liferay.faces.test.bridge.tck.main.portlet.chapter6_1_3_1Tests-encodeURLEscapingTest-portlet%21471674933%7C0;0/ __ac0/__av0;param2:b/ __av0;parm1:a/ __av0;_facesViewIdRender:%2Ftests%2FSingleRequestTest.jsf
Therefore the test should be changed so that the result of ExternalContext.encodeActionURL(String url) either contains encoded ampersands, or contains no ampersands at all. In addition, the test should not only consider the query-string, but the entire URL because Pluto 3.0's URL does not even have a question-mark 
character to indicate a query-string.