URL generation for links and resources doesn't work in Liferay environment

[twrobel]

Hi,
I posted https://issues.apache.org/jira/browse/WICKET-4882 against Wicket. I'm not sure if it is wicket or wicketstuff related problem though.

Thanks
Tomasz

[zeratul021]

It's a "Wicket problem". See my comments here:
https://issues.apache.org/jira/browse/WICKET-4645?focusedCommentId=13489620&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13489620

My solutions: either you provide custom URLRenderer as in this fork of portlets integration for Wicket 6:

https://github.com/zeratul021/core/commit/0209130543de8490a4972f55164c9900d2951a28

or use some bridging similar to:

https://github.com/zeratul021/core/tree/master/jdk-1.6-parent/portlet-parent/wicketstuff-portlet/src/test/java/org/apache/wicket/portlet

[twrobel]

Thanks Marek.
I saw your last comment to https://issues.apache.org/jira/browse/WICKET-4645, do you think Wicket is going to reintroduce this functionality? bug seems to be in resolved state. It would be great if we didn't need to have our custom URLRenderer.
Also, I think providing our own *HeaderItem classes could fix the issue for resource files, but then we are still left with link URLs not generating properly.

[zeratul021]

Hi,

well I can''t speak for the core team, but I didn't get any specific answer/follow-up on this problem. wicketstuff-portlet should be a bridge, and does quite intervening stuff regarding core request cycle funtionality. So even if it may seem as too intrusive, custom UrlRenderer probably fits just right in

Any way, I see 4645 as a regression for "portlet initiative" and unfortuantelly I didn't study the issue completely to understand why such fix was needed. I will try to have a look at it this week and see if something can be done. Trivially it's a matter of three lines of code being reintroduced.

P.S. I didn't notice link URL problems.

[twrobel]

Appreciate your comment. I just noticed that Martin marked the bug I reported (https://issues.apache.org/jira/browse/WICKET-4882) as invalid and suggested focusing on UrlRenderer. Considering that, do you think wicket-portlet could provide the implementation that is going to address that issue. To be honest I'm still hoping that it can be solved without the need to maintain our own version of wicketstuff/wicket.

[zeratul021]

Yes, I think so. But:

1. I think it would be reasonable to take the sources from the parent issue from Petr Pastrnak and just introduce the custom UrlRenderer in 1.5 branch (I'm not aware of other issues in that branch)
2. I cleaned up the codebase substantially during adoption of Wicket 6 and I probably will ask for pull request to master

So for the sake of commit readability in branches I would not merge from my master to 1.5 branch - everything would be marked as changed (code formatting, code cleanup, etc..)

[twrobel]

Thanks for your efforts Marek.
For the time being we ended up creating our own UrlRenderer class by extending the standard one and overriding renderRelativeUrl method:
@OverRide
public String renderRelativeUrl(final Url url) {
Validate.notNull(url, "url");
if (url.isAbsolute()) {
return url.toString();
}
return super.renderRelativeUrl(url);
}
Then in our app we replace requestCycleProvider with an implementation that is going to use the custom UrlRenderer.
This approach used with Wicket 1.5.9 solved the issue for us.
By the way, in the course of implementing the renderer seems like it would be nice if UrlRenderer had an interface, providing custom implementation would then give more flexibility.

[zeratul021]

Really nothing to thank for, at least for now.
My fork uses the same approach and it works for us, so good luck with your testing.

[andreynek]

Is it the same problem?: in Wicket6.6.0 resource URLs for DefaultNestedTree renders like:
/geo_editor1/ps:Z2VvX2VkaXRvcl9XQVJfZ2VvX2VkaXRvcjAxMFNOQVBTSE9UX0xBWU9VVF8xMDE4Mw/wicket/resource/org.apache.wicket.ajax.AbstractDefaultAjaxBehavior/res/js/wicket-event-jquery.min-ver-12C7F17AFBC0A319DF87D37B05A03AB8.js

where geo_editor1 - dir in
D:\liferay-portal-6.1.1-ce-ga2\tomcat-7.0.27\webapps\geo_editor1

Portlet name is "geo_editor", and this is missing in URL, right? I made modifications
if (url.isAbsolute()) {
return url.toString();
}
in \apache-wicket-6.6.0\wicket-request\src\main\java\org\apache\wicket\request\UrlRenderer.java
This help with other problems in URLs, but not in this problem. What can i do else?

[andreynek]

Wicket 6.7.0, wicketstuff-portlet 6.5.0 - not solved problem with missing porlet name, see comment above 172#issuecomment-15390878

[Artsu]

The issue andreynek reported prevented us from using ajax in wicket portlets as the ajax jquery scripts were not properly loaded. Managed to fix this by customizing PortletRequestMapper#encodeSharedResourceUrl urlBuilder. request.getFilterpath() seemed to return empty string. I changed this to ThreadPortletContext.getHttpServletRequest().getServletPath() and now it seems to work properly. This might not be the proper way to fix this and maybe one should just figure out why the filterpath was empty but for now this will do.

[FuadEfendi]

I tried to use AjaxEditableLabel to modify PortletPreferences; Liferay 6.2 CE & Wicket 6.18.0.

I think there is no any better solution than initially suggested https://github.com/zeratul021/core/commit/0209130543de8490a4972f55164c9900d2951a28

But it didn't work for me initially.

URLs for JavaScript were "relative"; it didn't work because JavaScript didn't know "base URL" and tried to access root context instead.

It worked for me with explicit (hardcoded) URL prefixing:

@Override
public String renderRelativeUrl(final Url url)
{
    Args.notNull(url, "url");
    if (url.isAbsolute())
    {
        return url.toString();
    }
    else
    {
        // return super.renderRelativeUrl(url);
        return "/t-portlets-portlet/search/" + url.toString();
    }
}

Here, "t-portlets-portlet" is explicit context of web application (in my scenario, subfolder in "webapps" with the same name, tomcat/webapps/t-portlets-portlet); "search" is Wicket filter mapping.

I am trying to find how to avoid hardcoding... it was initial step to make it working...

[FuadEfendi]

I think "client URL" has incorrect "base URL" settings such as "/web/guest/test" instead of "/t-portlets-portlet/view"; anyway, this works fine for me, with images, CSS, portlet preferences, AJAX, and etc.:

package ca.tokenizer.wicket;

import javax.servlet.http.HttpServletRequest;

import org.apache.wicket.request.Request;
import org.apache.wicket.request.Url;
import org.apache.wicket.request.UrlRenderer;
import org.apache.wicket.util.lang.Args;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class PortletUrlRenderer extends UrlRenderer
{

private static final Logger LOG = LoggerFactory.getLogger(PortletUrlRenderer.class);

private final String contextPath;

public PortletUrlRenderer(final Request request)
{
    super(request);
    final HttpServletRequest httpServletRequest = (HttpServletRequest) request.getContainerRequest();
    contextPath = httpServletRequest.getContextPath();
}

@Override
public String renderRelativeUrl(final Url url)
{

    LOG.debug("url: \t\t{}", url);
    Args.notNull(url, "url");
    String urlRendered;
    if (url.isContextAbsolute())
    {
        urlRendered = url.toString();
    }
    else
    {
        urlRendered = contextPath + super.renderRelativeUrl(url).substring(1);
    }

    LOG.debug("urlRendered:\t{}", urlRendered);
    return urlRendered;

}

}

[kkaravitis]

fixed on wicket-6.x, wicket-7.x and master branches