Hey Kito, thanks for reporting this. This looks like how trinidad
formats things. In trinidad, if a resource is "/dir/resource" it treats
this as webapp context meaning it apends the webapp name. Two leading
slashes is server context. Perhaps the default was coded wrong...
Scott
Kito D. Mann (JIRA) wrote:
PortletExternalContextImpl.encodeResourceURL seems to return prepend the
context path twice
-------------------------------------------------------------------------------------------
Key: PORTLETBRIDGE-19
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-19
Project: MyFaces Portlet Bridge
Issue Type: Bug
Components: Impl
Affects Versions: 1.0.0-SNAPSHOT
Environment: exo-enterprise-webos-r21645 (includes Tomcat 6.0.10), JSF RI 1.2_05 and Windows XP
Reporter: Kito D. Mann
I've been experimenting with several portlet bridges with the standard
guessnumber app. The following JSF tag declaration:
<h:graphicImage id="waveImg" url="/wave.med.gif" />
Generates this URL with the portlet bridge:
<img id="I26380823I:j_id_jsp_1712459602_0:helloForm:waveImg"
src="/guessnumberportlet-301/guessnumberportlet-301/wave.med.gif" />
In this application, the web app _and_ the portlet have the same name "guessnumberportled-301". I've tested eXo with he MyFaces and Apache Portals bridges, and neither of them have this problem, so I think this may be a problem with this particular bridge.
Everything works fine with if you remove the first slash:
<h:graphicImage id="waveImg" url="wave.med.gif" />
This generates the expected outcome:
<img id="I26380823I:j_id_jsp_1712459602_0:helloForm:waveImg"
src="/guessnumberportlet-301/wave.med.gif" />
I haven't had a chance to actually step through the bridge's code or try this
in Pluto.
