Wicket
  1. Wicket
  2. WICKET-4330

Non standard ("wicket") namespace causes incorrect relative URL in certain cases

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.5.3
    • Fix Version/s: 1.5.5, 6.0.0-beta1
    • Component/s: wicket
    • Labels:
    • Environment:
      Win XP, 4GB RAM, Tomcat 6, Java 6

      Description

      The problem is related to non standard (i.e. "wicket") namespaces.

      In my quickstart if I change the namespace in all markup from "wicket"
      to "foobar" then the BPL which has only the last segment differing from the current page ends up producing an incorrect link to another page in the same path.

      i.e.

      Browser is at this page:
      http://127.0.0.1/content/other/o/1234/aspect/fred

      <p>
      Here's a relative link to another page in the same 'path'
      <div>
      <a foobar:id="janeLink" href="../../../../../jane"
      style="outline: 0;">
      jane
      </a>
      </div>
      </p>
      <p>
      A link to the current page
      <a foobar:id="fredLink" href="fred">fred</a> </p>

      The above BPL href of ../../../../../jane is wrong.

      With 'wicket' set as the namespace the 'jane' BPL outputs 'jane' which is correct.

      This same code worked with the non standard namespace under 1.4.x

      Attached quickstart demonstrates the issue.

        Activity

        Hide
        Chris Colman added a comment -

        Thanks Martin! That works really well now.

        Show
        Chris Colman added a comment - Thanks Martin! That works really well now.
        Hide
        Martin Grigorov added a comment -

        All is fine.
        It appears that org.apache.wicket.markup.parser.filter.WicketNamespaceHandler is responsible to extract the namespace from <html xmlns:...> and set it for the MarkupResourceStream.
        I'll fix the issues in the comments above.

        Show
        Martin Grigorov added a comment - All is fine. It appears that org.apache.wicket.markup.parser.filter.WicketNamespaceHandler is responsible to extract the namespace from <html xmlns:...> and set it for the MarkupResourceStream. I'll fix the issues in the comments above.
        Hide
        Chris Colman added a comment -

        That must be a change since 1.4.x where we've been using different namespaces that were specified purely at the markup level with no Java code to specify them.

        Show
        Chris Colman added a comment - That must be a change since 1.4.x where we've been using different namespaces that were specified purely at the markup level with no Java code to specify them.
        Hide
        Martin Grigorov added a comment -

        AFAIK you need to configure the namespace with org.apache.wicket.markup.AbstractMarkupParser#setWicketNamespace().
        I haven't had time to debug how now <foobar:panel> actually works.
        But even with #setWicketNamespace("foobar") the problems in my previous comment will break your application.

        Show
        Martin Grigorov added a comment - AFAIK you need to configure the namespace with org.apache.wicket.markup.AbstractMarkupParser#setWicketNamespace(). I haven't had time to debug how now <foobar:panel> actually works. But even with #setWicketNamespace("foobar") the problems in my previous comment will break your application.
        Hide
        Chris Colman added a comment -

        > You don't specify anywhere that 'foobar' is a replacement for 'wicket' namespace. Or at least I don't see it.

        It's specified in the html tag of each markup file. That was all that was required to change the namespace in 1.4.x. In fact in 1.4.x we even had some markup specified with "wicket" namespace and others specified with "foobar" namespace and it worked perfectly - even markup inheritance worked with markups in the hierarchy having different namespaces.

        Are you saying that in 1.5.x we need to specify a namespace change in the java code somewhere?

        > General: Namespace should not be a constant

        I had a hunch that some hard coded "wicket" namespace references in 1.5.x might be related or the cause of the issue.

        Show
        Chris Colman added a comment - > You don't specify anywhere that 'foobar' is a replacement for 'wicket' namespace. Or at least I don't see it. It's specified in the html tag of each markup file. That was all that was required to change the namespace in 1.4.x. In fact in 1.4.x we even had some markup specified with "wicket" namespace and others specified with "foobar" namespace and it worked perfectly - even markup inheritance worked with markups in the hierarchy having different namespaces. Are you saying that in 1.5.x we need to specify a namespace change in the java code somewhere? > General: Namespace should not be a constant I had a hunch that some hard coded "wicket" namespace references in 1.5.x might be related or the cause of the issue.
        Hide
        Martin Grigorov added a comment -

        org.apache.wicket.markup.html.form.AutoLabelTextResolver.TextLabel#findLabelContent has:

        String text = formComponent.getDefaultLabel("wicket:unknown");
        if (!"wicket:unknown".equals(text) && !Strings.isEmpty(text))

        I'm not sure wicket:unknown is even documented anywhere... :-/

        Show
        Martin Grigorov added a comment - org.apache.wicket.markup.html.form.AutoLabelTextResolver.TextLabel#findLabelContent has: String text = formComponent.getDefaultLabel("wicket:unknown"); if (!"wicket:unknown".equals(text) && !Strings.isEmpty(text)) I'm not sure wicket:unknown is even documented anywhere... :-/
        Hide
        Martin Grigorov added a comment -

        wicket:message wont work as well with changed namespace:

        /** TODO Post 1.2: General: Namespace should not be a constant */
        private final static String WICKET_MESSAGE_ATTRIBUTE_NAME = "wicket:message";

        Show
        Martin Grigorov added a comment - wicket:message wont work as well with changed namespace: /** TODO Post 1.2: General: Namespace should not be a constant */ private final static String WICKET_MESSAGE_ATTRIBUTE_NAME = "wicket:message";
        Hide
        Martin Grigorov added a comment -

        Otherwise the problem seems to be the check for "wicket:id" in org.apache.wicket.markup.parser.filter.RelativePathPrefixHandler#onComponentTag().
        It doesn't honor changed namespaces for MarkupParser (I still don't see you doing this anyway).

        Show
        Martin Grigorov added a comment - Otherwise the problem seems to be the check for "wicket:id" in org.apache.wicket.markup.parser.filter.RelativePathPrefixHandler#onComponentTag(). It doesn't honor changed namespaces for MarkupParser (I still don't see you doing this anyway).
        Hide
        Martin Grigorov added a comment -

        How this application even works ?
        You don't specify anywhere that 'foobar' is a replacement for 'wicket' namespace. Or at least I don't see it.

        Show
        Martin Grigorov added a comment - How this application even works ? You don't specify anywhere that 'foobar' is a replacement for 'wicket' namespace. Or at least I don't see it.
        Hide
        Chris Colman added a comment -

        The cause of the issue seems to be that the BPL tag is incorrectly having the RelativePathPrefixHandler invoked on it. With the non standard namespace Wicket confuses this BPL for a non wicket tag and so applies that filter which causes the damage to the href when it attempts to make an already relative link relative ... again

        Show
        Chris Colman added a comment - The cause of the issue seems to be that the BPL tag is incorrectly having the RelativePathPrefixHandler invoked on it. With the non standard namespace Wicket confuses this BPL for a non wicket tag and so applies that filter which causes the damage to the href when it attempts to make an already relative link relative ... again
        Hide
        Chris Colman added a comment -

        Quickstart - uses port 80, not 8080!

        Show
        Chris Colman added a comment - Quickstart - uses port 80, not 8080!

          People

          • Assignee:
            Martin Grigorov
            Reporter:
            Chris Colman
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development