Mailing-List: contact jetspeed-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jetspeed Developers List" <jetspeed-dev@jakarta.apache.org>
Message-ID: <869876166.1080830444431.JavaMail.apache@nagoya>
Date: Thu, 1 Apr 2004 06:40:44 -0800 (PST)
From: jira@apache.org
To: jetspeed-dev@jakarta.apache.org
Subject: [jira] Created: (JS2-4) ActionURL parameters not accessible: wronly
 encoded
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:
  http://issues.apache.org/jira/browse/JS2-4

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: JS2-4
    Summary: ActionURL parameters not accessible: wronly encoded
       Type: Bug

     Status: Unassigned
   Priority: Blocker

    Project: Jetspeed 2
   Versions:
             2.0-dev/cvs

   Assignee: 
   Reporter: Ate Douma

    Created: Thu, 1 Apr 2004 6:38 AM
    Updated: Thu, 1 Apr 2004 6:38 AM
Environment: WindowsXP, J2SE 1.4.2_03, Tomcat 4.1.29

Description:
o.a.j.services.information.PortletURLProviderImpl.toString() encodes ActionURL parameter using pluto's NamespaceMapper.encode(...).

This seems to be copied from pluto's o.a.p.portalImpl.core.PortletURLProviderImpl.toString() where the exact same handling can be found BUT there its commented out! (since the first version in cvs even).

The result of the current implementation is that ActionURL parameters are prefixed by 'Pluto_[PortletWindowId]_'. These parameters are thus not accessible by their expected name in processAction.

In Pluto, ActionURL parameters are simply non-encoded put into the url which to me seems perfectly fine as only one portlet can be target with an ActionURL and its id is already encoded otherwise in the url. ActionURL parameters thus can be treated just like normal form parameters (non of these will be propagated as render parameters anyway).

So, my suggestion is to remove the NamespaceMapper.encode(...) handling in o.a.j.services.information.PortletURLProviderImpl.toString() just as in Pluto.

Note: the current cvs state of ActionURL and RenderURL seems to be broken (no parameters are rendered anymore). I tested this on a cvs checkout from 2004-03-26)


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org