portlet url non conformance to api

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

Weird!

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.

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).

Fixed in CVS.

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

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

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

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

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