[jira] Assigned: (PLUTO-517) PortletWindowConfig#createPortletId generates troublesome id with leading slash

["Ate Douma (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/PLUTO-517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ate Douma reassigned PLUTO-517:
-------------------------------

    Assignee: Ate Douma

> PortletWindowConfig#createPortletId generates troublesome id with leading slash
> -------------------------------------------------------------------------------
>
>                 Key: PLUTO-517
>                 URL: https://issues.apache.org/jira/browse/PLUTO-517
>             Project: Pluto
>          Issue Type: Bug
>          Components: portal driver
>    Affects Versions: 2.0.0
>            Reporter: Antony Stubbs
>            Assignee: Ate Douma
>
> PortletWindowConfig#createPortletId uses the context as the beginning of the ID, but leaves the leading slash on if it exists. This is troublesome for parsing to resultant portlet id from urls (for example with Wicket portlet support). The reason to avoid '/' in the portlet id is so that you can discover the portlet id, by simply looking between two slashes.
> I propose the following:
> {code}
>         String trimContextPath = null;
> 		if (contextPath.startsWith("/"))
> 		{
> 			trimContextPath = contextPath.substring(1);
> 		}
> 		else
> 		{
> 			trimContextPath = contextPath;
> 		}
> 		return trimContextPath + "." + portletName + "!" + metaInfo;
> {code}
> Is the a reason why the leading slash should be kept for portlet ids?
> After further investigation, this doesn't seem to be where the portlet id is actually generated.
> However, it does seem to do. I'm afraid of the inconsistencies this change may introduce though.
> However, there seems to be a circular sort of dependency (which is why i thought it wasn't generated there), as some code relies on being able to extract the context path from the portal ID, so I also added this:
> PortletWindowConfig#parseContextPath:
>     public static String parseContextPath(String portletId) {
>     	int index = getSeparatorIndex(portletId);
>         String context = portletId.substring(0, index);
>         if (!context.startsWith("/"))
> 		{
> 			context = "/" + context;
> 		}
> 		return context;
>     }
> this makes sure that the context path always starts with a / as is required by the servlet context look-up functions.
> So to sum it up, this removes the / from the beginning of the portlet id, so the wicket portal urls end up looking like:
> http://localhost:8080/non-gizmo-wicket-portlet/wicket/ps:non-gizmo-wicket-portlet.HelloWorld-PotletName!-649619114|0/resources/org.apache.wicket.markup.html.WicketEventReference/wicket-event.js
> instead of:
> http://localhost:8080/non-gizmo-wicket-portlet/wicket/ps:/non-gizmo-wicket-portlet.HelloWorld-PotletName!-649619114|0/resources/org.apache.wicket.ajax.WicketAjaxReference/wicket-ajax.js
> which appears to work with the current wicket/portal implementation, as it looks for the portlet id between the two /'s.
> nb of course that this may effect other portal web frameworks as well.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.