portlet url non conformance to api

• Type: Bug
• Status: Closed
• Priority: Critical
• Resolution: Fixed
• Affects Version/s: 3.5.0
• Fix Version/s: None
• Component/s: None
• Labels: None
• Environment: jdk 1.4; liferay pro 3.5
• Similar Issues: Show 5 results ; ;

  LEP-6213	Provide implementation for new API defined by the Mirage CMS project: http://mirage.dev.java.net/
  LEP-2881	Page not found (HTTP 404) for non-existing resources
  LEP-265	WSRP Proxy Portlet Not Working with Non-root Context
  LEP-6903	Google Search does not work with AJAX Search API key.
  LEP-3572	Liferay needs a Javascript API for url manipulation

It seems that when I create a PortletURL and set a parameter, then use .toString to display this url for use, the parameter is set.

However, if i use the same url object, and set the parameter to another value, instead of changing the existing value, it creates another parameter in the list.

e.g. parameter method

PortletURL url = null;
url = response.createRenderURL();
System.out.println("DAVViewingPortlet.addNavigation : url : " + url.toString( ) );
url.setParameter( "method", "CreateCollection" );
System.out.println("DAVViewingPortlet.addNavigation : url : " + url.toString( ) );
url.setParameter( "method", "UploadFile" );
System.out.println("DAVViewingPortlet.addNavigation : url : " + url.toString( ) );

DAVViewingPortlet.addNavigation : url : http://127.0.0.1:8080/c/portal/layout?p_l_id=1&p_p_id=davviewing_WAR_davviewing&p_p_action=0&p_p_state=normal&p_p_mode=view&p_p_width=536&p_p_col_order=w1&p_p_col_pos=0&p_p_col_count=1&#p_davviewing_WAR_davviewing
DAVViewingPortlet.addNavigation : url : http://127.0.0.1:8080/c/portal/layout?p_l_id=1&p_p_id=davviewing_WAR_davviewing&p_p_action=0&p_p_state=normal&p_p_mode=view&p_p_width=536&p_p_col_order=w1&p_p_col_pos=0&p_p_col_count=1&_davviewing_WAR_davviewing_method=Home&_davviewing_WAR_davviewing_method=CreateCollection&#p_davviewing_WAR_davviewing
DAVViewingPortlet.addNavigation : url : http://127.0.0.1:8080/c/portal/layout?p_l_id=1&p_p_id=davviewing_WAR_davviewing&p_p_action=0&p_p_state=normal&p_p_mode=view&p_p_width=536&p_p_col_order=w1&p_p_col_pos=0&p_p_col_count=1&_davviewing_WAR_davviewing_method=Home&_davviewing_WAR_davviewing_method=CreateCollection&_davviewing_WAR_davviewing_method=UploadFile&#p_davviewing_WAR_davviewing
D

The last url has two method parameters set to diferent values.

Cheers

Paul.

[Paul Hussein]

Also when trying to extract the parameter, the value is sometimes extractable, sometimes not.

Weird!

[Paul Hussein]

OK guys, I had a look at the CVS and it seems you changed the behavior of
PortletURLImpl.setParameter to ' appends parameters' on release 3.5

Branch: MAIN
CVS Tags: RELEASE_3_5_0, HEAD
Changes since 1.52: +11 -3 lines
Diff to previous 1.52

PortletURLImpl.setParameter appends parameters, this is according to the spec
We added another param "append", that defaults to true to keep with the spec, but
if you specify "false", it won't append but will overwrite. This would explain the behavior I am
seeing in my stuff.

However, if I look at the spec, it says

'This method replaces all parameters with the given key.' as below:

setParameter

public void setParameter(java.lang.String name,
java.lang.String value)

Sets the given String parameter to this URL.

This method replaces all parameters with the given key.

The PortletURL implementation 'x-www-form-urlencoded' encodes all parameter names and values. Developers should not encode them.

A portlet container may prefix the attribute names internally in order to preserve a unique namespace for the portlet.

Parameters:
name - the parameter name
value - the parameter value
Throws:
java.lang.IllegalArgumentException - if name or value are null.

I also took a look at createRenderURl and createActionURL to check if there was something in there, but nothing
seems to indicate any appending behavior, in fact quite the opposite
'The created URL will per default not contain any parameters of the current render request'

public PortletURL createRenderURL()

Creates a portlet URL targeting the portlet. If no portlet mode, window state or security modifier is set in the PortletURL the current values are preserved. If a request is triggered by the PortletURL, it results in a render request.

The returned URL can be further extended by adding portlet-specific parameters and portlet modes and window states.

The created URL will per default not contain any parameters of the current render request.

Returns:
a portlet render URL

Which part of the spec did you read to come to the append conclusion, I can see only add or replace.

Cheers

Paul.

[Brian Chan]

This is bizarre. I swear a few weeks/months ago someone brought up the same issue but had some notes to point otherwise. For now, to make everyone happy, I'll make the default behavior configurable, but have it default to YOUR way (which seems to be more reliable according to the notes you just mentioned).

[Brian Chan]

Fixed in CVS.

[Brian Chan]

CVS COMMIT LOG:
SUBJECT: [Lportal-cvs-commits] portal/portal-ejb/src/com/liferay/portlet PortletURLImpl.java,1.53,1.54
LEP-426

[Brian Chan]

CVS COMMIT LOG:
SUBJECT: [Lportal-cvs-commits] portal/portal-ejb/src/com/liferay/portal/util PropsUtil.java,1.138,1.139
LEP-426

[Brian Chan]

CVS COMMIT LOG:
SUBJECT: [Lportal-cvs-commits] portal/portal-ejb/src/com/liferay/portal/struts StrutsURLEncoder.java,1.14,1.15
LEP-426

[Brian Chan]

CVS COMMIT LOG:
SUBJECT: [Lportal-cvs-commits] portal/portal-ejb/classes portal.properties,1.234,1.235
LEP-426

[Raymond Auge]

Hello Paul,

My name is Raymond Auge. I'm a Liferay user and I'm trying to integrate
Slide into Liferay. I'm having a problem with jaas authentication. Since
you're our resident expert on the subject I thought that I might ask you
for advice.

I'll show you what I'm trying and perhaps you can tell me what I'm doing
wrong:

--> configure slide for jaas
slide.xml:
<Context path="/slide" debug="0" privileged="true" useNaming="true">
<Realm className="org.apache.catalina.realm.JAASRealm"
appName="slide_login"
userClassNames="com.liferay.portal.jaas.PortalPrincipal"
roleClassNames="com.liferay.portal.jaas.PortalRole"
debug="99"
useContextClassLoader="false"
/>

</Context>

--> add jaas config
jaas.config: (loaded at tomcat startup)
PortalRealm {
com.liferay.portal.jaas.PortalLoginModule required;
};

slide_login {
com.liferay.portal.jaas.PortalLoginModule required;
};

--> configure the rest of slide
-->enable authentication in slide/WEB_INF/web.xml
-->added
<auto-create-users>true</auto-create-users>
<auto-create-users-role>org.apache.slide.structure.SubjectNode</auto-create-users-role>
to Domain.xml

--> slide is deployed in it's own webapp (this could be the problem)

Thanks,

Raymond