Forrest
  1. Forrest
  2. FOR-284

link rewriting broken when linking to xml source which contain site: links

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Incomplete
    • Affects Version/s: 0.6, 0.7, 0.8
    • Fix Version/s: 0.7, 0.8
    • Component/s: Launch 'forrest'
    • Labels:
      None

      Description

      When linking to *.xml files (e.g. to demonstrate a source file) then if that file contains "site:" or "ext:" links, then they are reported as broken, e.g. docs/site:dtd-docs

        Issue Links

          Activity

          Hide
          Nicola Ken Barozzi added a comment -
          Committed a temporary fix by disabling the 'error:' prepending to links not resolves in site.xml.

          Does not need to be solved for 0.6 anymore.
          Show
          Nicola Ken Barozzi added a comment - Committed a temporary fix by disabling the 'error:' prepending to links not resolves in site.xml. Does not need to be solved for 0.6 anymore.
          Hide
          Nicola Ken Barozzi added a comment -
          Now that I know what this is about I can better describe it.
          Show
          Nicola Ken Barozzi added a comment - Now that I know what this is about I can better describe it.
          Hide
          Rick Tessner added a comment -
          It looks like the problem arises only when there is a link reference to the ".xml" file that contains the "site:" or "ext:" references.

          For example, if we have a document called "sample.xml" and there is a link in that document of the form <a href="sample.xml">, the "forrest site" will fail with the broken link message.

          This is exactly what we have in the samples/sample.xml. There is in the "Presentations" section: <a href="samples.xml">.

          Removing that link will result in a "forrest site" completing cleanly. However, that's not the solution.

          I'm guessing that the problem resides in the "linkrewriter" transform somewhere.
          Show
          Rick Tessner added a comment - It looks like the problem arises only when there is a link reference to the ".xml" file that contains the "site:" or "ext:" references. For example, if we have a document called "sample.xml" and there is a link in that document of the form <a href="sample.xml">, the "forrest site" will fail with the broken link message. This is exactly what we have in the samples/sample.xml. There is in the "Presentations" section: <a href="samples.xml">. Removing that link will result in a "forrest site" completing cleanly. However, that's not the solution. I'm guessing that the problem resides in the "linkrewriter" transform somewhere.
          Hide
          Rick Tessner added a comment -
          I should add a quick note here about FOR-293 as well. It appears that the fix to the declare-broken-site-links.xsl caused some other issues and that's what FOR-293 is about.
          Show
          Rick Tessner added a comment - I should add a quick note here about FOR-293 as well. It appears that the fix to the declare-broken-site-links.xsl caused some other issues and that's what FOR-293 is about.
          Hide
          David Crossley added a comment -
          Rick's explanation sparked a recollection that something was fixed a few months ago which might be related. We used to get error messages, due to those "site:" links via the linked examples in sitemap-ref.html
          http://cvs.apache.org/viewcvs.cgi/forrest/trunk/src/core/context/WEB-INF/cli.xconf?root=Apache-SVN
          Show
          David Crossley added a comment - Rick's explanation sparked a recollection that something was fixed a few months ago which might be related. We used to get error messages, due to those "site:" links via the linked examples in sitemap-ref.html http://cvs.apache.org/viewcvs.cgi/forrest/trunk/src/core/context/WEB-INF/cli.xconf?root=Apache-SVN
          Hide
          Rick Tessner added a comment -
          Seems to be related to FOR-258 (or may even end up being a duplicate of that issue).
          Show
          Rick Tessner added a comment - Seems to be related to FOR-258 (or may even end up being a duplicate of that issue).
          Hide
          David Crossley added a comment -
          Changed the issue title and description to better reflect the real problem.
          Show
          David Crossley added a comment - Changed the issue title and description to better reflect the real problem.
          Hide
          David Crossley added a comment -
          This issue was well-described in Issue FOR-156 which was closed with a workaround. This workaround was partially disabled (see above). So now the problem appeared again, but the links were being excluded via cli.xconf so we didn't see any broken site: links.

          I can see a way to restore the original workaround and not have its side-effects.
          Show
          David Crossley added a comment - This issue was well-described in Issue FOR-156 which was closed with a workaround. This workaround was partially disabled (see above). So now the problem appeared again, but the links were being excluded via cli.xconf so we didn't see any broken site: links. I can see a way to restore the original workaround and not have its side-effects.
          Hide
          David Crossley added a comment -
          The workaround for FOR-156 was so close to working. Its trouble was only that it needed to deal with docs in sub-directories as well as at top-level. This needed one more exclude pattern in cli.xconf

          The workaround was re-implemented at http://svn.apache.org/viewcvs?view=rev&rev=161617

          In the core sitemap, after the linkrewriter, the transformer declare-broken-site-links.xsl prepends "error:" to definite broken site: or ext: links. The bogus broken link reporting due to this issue 284 then remain. They will commence with string site:** or docs/site:** etc. These URIs are then excluded by entries in cli.xconf
          Show
          David Crossley added a comment - The workaround for FOR-156 was so close to working. Its trouble was only that it needed to deal with docs in sub-directories as well as at top-level. This needed one more exclude pattern in cli.xconf The workaround was re-implemented at http://svn.apache.org/viewcvs?view=rev&rev=161617 In the core sitemap, after the linkrewriter, the transformer declare-broken-site-links.xsl prepends "error:" to definite broken site: or ext: links. The bogus broken link reporting due to this issue 284 then remain. They will commence with string site:** or docs/site:** etc. These URIs are then excluded by entries in cli.xconf
          Hide
          David Crossley added a comment -
          The workaround using cli.xconf has been working nicely.
          Show
          David Crossley added a comment - The workaround using cli.xconf has been working nicely.
          Hide
          David Crossley added a comment -
          This appears to be fixed.
          Show
          David Crossley added a comment - This appears to be fixed.
          Hide
          David Crossley added a comment -
          Set the issue Resolution to be "Incomplete". We have a workaround in Cocoon's cli.xconf but the real cause of the issue is not fixed.
          Show
          David Crossley added a comment - Set the issue Resolution to be "Incomplete". We have a workaround in Cocoon's cli.xconf but the real cause of the issue is not fixed.

            People

            • Assignee:
              Unassigned
              Reporter:
              Nicola Ken Barozzi
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development