Liferay faces bridge 3.0.0-BETA2 / Url context structure

[Markus Maier, modificado 11 Anos atrás.]

Hello!

I am currently migrating a jsf 1.2 project (jboss portlet bridge) to a jsf 2.1 project (liferay portlet bridge).

The project has lots of views that reference custom servlets registered on portal level:

<h:outputlink value="/portalservletcontext/">
	linktext
	<f:param name="id" value="123" />
	<f:param name="name" value="abc" />
</h:outputlink>

Previously this markup generated links like:

http://liferayserver:liferayport/portalservletcontext/?id=123&name=abc

Now with the new bridge i get an extra portletcontext inserted into all urls:

http://liferayserver:liferayport/portletcontext/portalservletcontext/?id=123&name=abc

Because of that additional context, the generated urls are no longer handled by the portal level servlets.

I debugged into

com.liferay.faces.bridge.context.url.BridgeResourceURLImpl.toBaseURL() 

but there doesn't seem to be a case that generates the urls i would require (without the portletcontext inserted).

How can i best solve that problem? I also tried the new Beta3 of the Jboss portlet bridge, the portletcontext is not inserted there, but i am not sure why links work differently with that bridge. Are there any plans to change/enhance the link generating for the final version of the Liferay faces bridge?

Thanks,

Max

Environment:
Liferay 6.0.6
Liferay Faces Bridge 3.0.0-BETA2
Mojarra 2.1.7

[Neil Griffin, modificado 11 Anos atrás.]

Hi Markus,

Liferay Faces Bridge implements the JSR 329 spec so that all of the Test Compatibility Kit (TCK) tests pass, which would include tests regarding generation of URLs. We can try and support your use case, but we would have to do it in such a way that the TCK tests continue to pass.

Are you sure that h:outputLink is calling BridgeResourceURLImpl.toBaseURL() and not BridgeActionURLImpl.toBaseURL() ?

Thanks,

Neil

[Markus Maier, modificado 11 Anos atrás.]

Hello Neil,

thank you for your quick reply.

I just re-checked with the debugger, actually the class

com.liferay.faces.bridge.context.url.liferay.BridgeResourceURLLiferayImpl

is called by the output link, and it uses the inherited method from the class BridgeResourceURLImpl.

I think it's not an uncommon usecase to call portal servlets from a portlet and it would be great if you could support it in some way!

Thanks,

Max

[Neil Griffin, modificado 11 Anos atrás.]

OK thanks for finding that in the debugger. In the case of URLs that start with a forward-slash like /portalservletcontext the JSR 329 spec requires that the context-path be prepended. In the case of Liferay Faces Bridge, the BaseURLEncodedInternalStringImpl class does the prepending operation.

Questions for you:
1) What app server are you using?
2) In your specific situation, what is the actual value of /portalservletcontext ?

[Markus Maier, modificado 11 Anos atrás.]

Hello Neil!

1) I am using the Liferay Portal Server 6.0.6 CE.
2) One specific value would be /handleResource (+ various parameters) that maps to a custom portal servlet that globally serves and caches resources, images for example. Another portal servlet maps logical names to configured liferay pages, an example call in that case would be /callpage?page=home. When the user clicks the respective link he is redirected to the appropriate location.

Best regards,

Max

[Neil Griffin, modificado 11 Anos atrás.]

Hi Max,

Are you using Tomcat? Also, can you paste here an actual absolute path to one of your servlets? Would it be like the following, referencing the ROOT context?
http://servername:port/callpage?page=home

Thanks,

Neil

[Markus Maier, modificado 11 Anos atrás.]

Hello Neil,

yes, the Liferay is set up on top of Apache Tomcat 6.
The url structure that you have assumed is exactly what the current bridge for jsf 1.2 is rendering!
The beta of the Liferay Faces Bridge is inserting the additional portlet-context and outputs that url like this:
http://servername:port/portlet-name/callpage?page=home

I also thought about reconfiguring the servlet mappings but i might run into conflicts there and would prefer a solution without that additional context in the url.

Best regards,

Max

[Neil Griffin, modificado 11 Anos atrás.]

If you specify an absolute URL (one that includes the http://servername part) then it might work without making any changes to the bridge. You can easily do this by adding the Liferay Faces Portal dependency to your portlet project. It contains an EL keyword named "liferay" that you could use like this:

<h:outputlink value="#{liferay.portalURL}/callpage?page=home" />

[Markus Maier, modificado 11 Anos atrás.]

Hello Neil!

I've tried prepending the portalURL to existing links (with both the EL-keyword and the respective method call LiferayFacesContext.getInstance().getPortalURL()) and thus making them absolute. It worked because the bridge then treats the url as external url and inserts no portlet context. The problem with that workaround is, that it cannot be used in libraries that are shared across portlets with different bridges (common taglibs for example).

I have reconfigured the portlet to use the latest Jboss Portlet Bridge (beta3) to see how such relative links are handled differently there.

The code that handles the encoding there is located in

org.jboss.portletbridge.context.PortletExternalContextImpl.encodeResourceURL(String)

Line 625:
else if (!isInContext(portalUrl)) {
    // 2) hierarchial url outside context.
    encodeBackLink(portalUrl);
    return encodeURL(portalUrl.toString());

Would be great if you could have a look at it and how i could achieve a similiar behavior with the liferay-optimized Liferay Faces Bridge.

Thank you,

Max

[Neil Griffin, modificado 11 Anos atrás.]

Hi Markus,

Glad to hear that the absolute path worked.

Regarding the code you mentioned, if the context-path is not prepended, then the TCK "encodeResourceURLTest" will fail. I think the problem here is that the JSR 329 spec doesn't seem to support your use-case.

In order to utilize the absolute path solution in app your portlets, you could do something like the following in your libraries that are shared across portlets with different bridges:

public String getPortalURL(PortletRequest portletRequest) {
    ThemeDisplay themeDisplay = (ThemeDisplay) getPortletRequest().getAttribute(WebKeys.THEME_DISPLAY);
    return themeDisplay().getPortalURL();
}

Kind Regards,

Neil

[Neil Griffin, modificado 11 Anos atrás.]

@Max: It turns out that you were right the whole time. Please see the last few comments of FACES-1331 for more info. The fix will appear in the GA1 release of Liferay Faces.