Wicket
  1. Wicket
  2. WICKET-1731

When used in inherited markup, <wicket:link> tries to load a class with an illegal name

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.3.4
    • Fix Version/s: 1.3.5, 1.4-RC1
    • Component/s: wicket
    • Labels:
      None
    • Environment:
      Mac OS X 10.4.11, Java 1.5.0_13, Tomcat 6.0.16

      Description

      Here are the classes involved. Each one has a .html markup file. The actual app is more complicated than this, but I've reduced it to a simple example.

      myapp.TemplatePage: Page with standard header that is extended by all other pages. Includes this autolink:

      <wicket:link><a href="HomePage.html">Home</a></wicket:link>

      myapp.HomePage: Main page of the application.
      myapp.login.LoginPage: Requests a user's login and password.

      When I try to access LoginPage, I get a NoClassDefFoundError: IllegalName: myapp/HomePage

      I have determined why this is occurring. AutoLinkResolver resolves autolinks to classes first by trying to load a class relative to the page's package, then relative to the parent page's package. However, the first time it calls Packages.absolutePath, it passes the output to Strings.replaceAll to replace forward slashes with periods, while the second time, it doesn't, which leads to the IllegalName error.

      The solution is to invoke the class-name-mangling logic from AutoLinkResolver.java lines 396-400 again after the call to Packages.absolutePath on line 428.

      Also, I'm suspicious of the logic for handling parent markup containers in AutoLinkResolver. It uses "if" instead of "while." What if the autolink was two levels up in the inheritance hierarchy? I think that it should walk the parent links until it finds a null, not just check the first one.

        Issue Links

          Activity

          Hide
          Willis Blackburn added a comment -

          How about my comment at the end?

          "Also, I'm suspicious of the logic for handling parent markup containers in AutoLinkResolver. It uses 'if' instead of 'while.' What if the autolink was two levels up in the inheritance hierarchy? I think that it should walk the parent links until it finds a null, not just check the first one."

          Show
          Willis Blackburn added a comment - How about my comment at the end? "Also, I'm suspicious of the logic for handling parent markup containers in AutoLinkResolver. It uses 'if' instead of 'while.' What if the autolink was two levels up in the inheritance hierarchy? I think that it should walk the parent links until it finds a null, not just check the first one."
          Hide
          Roland Huss added a comment -

          very same issue

          Show
          Roland Huss added a comment - very same issue
          Hide
          Roland Huss added a comment -

          WICKET-1634 is the same issue (including a patch), so this one can be closed, too

          Show
          Roland Huss added a comment - WICKET-1634 is the same issue (including a patch), so this one can be closed, too

            People

            • Assignee:
              Igor Vaynberg
              Reporter:
              Willis Blackburn
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development