Structurer does not work with "site:" protocol in site.xml

• Key: FOR-738
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Critical
• Assignee: Unassigned
• Reporter: Ross Gardler
• Component/s: Plugin: internal.dispatcher
• Affects Version/s: 0.8

Description

If site.xml contains a 'site:' protocol link then the docs cannot be generated. I've narrowed this down to the linkrewrter which fails with a stack overflow error.

Comments

[David Crossley]

I did some investigation. Adding such an entry to the seed-sample site, shows that it fails there too. However, it just gives a simple broken link message, whereas in a dispatcher-enabled site it gives that stack overflow.

Some other observations about a skins-enabled seed-sample site: Everything is fine for the left-hand navigation menu. The entry will display properly and the link is correct. However, when linking from the body of a document, then the link fails.

Also the same behaviour with forrest_07_branch: okay in the menu and broken in the body.

Another observation from our "site-author" docs where we use such "site:" links for the pluginDocs tab. The links display properly on the sub-tabs.

To summarise: Using such a link in the body of a page, gives the normal broken link message in both skins-enabled and dispatcher-enabled sites (remove the "label" attribute of the site.xml entry). With the skins-enabled site, the navigation menu works properly. With the dispatcher-enabled site, the generation of the menu pipeline fails with a "stack overflow".

The overflow may be caused by indirection beteen the sitemap and the locationmap in v2.

Current technique for resolving this is ignoring it until v3 starts to stabalise as it may just "go away" with the changes in v3.

For more info:

http://marc.theaimsgroup.com/?l=forrest-dev&m=113775438507448&w=2

[Thorsten Scherler]

Actually I did a test with the last dispatcher plugins (based on v3) and it is not going away. We need to fix the jx stuff.

[Thorsten Scherler]

We need to fix this ASAP otherwise it is a real bummer for the dispatcher because many sites using the linkrewritter stuff.

[Thorsten Scherler]

I partly fixed this issue by removing the dispatcher specific linkmap implementation (this is lowering the priority).

The linkrewritting in e.g. index.html is working fine again but still I get java.lang.OutOfMemoryError if I use it in the site.xml.

[Thorsten Scherler]

If you comment following contracts everything is working fine:
<forrest:contract name="nav-main" dataURI="cocoon://#{$getRequest}.navigation.xml"/>
<forrest:contract name="nav-main-sub" dataURI="cocoon://#{$getRequest}.navigation.xml"/>
<forrest:contract name="nav-section" dataURI="cocoon://#{$getRequest}.navigation.xml">
  <forrest:property name="toc" max-depth="2"/>
</forrest:contract>

All this contracts have in common that they are using *.navigation.xml.

Requesting http://localhost:8888/index.navigation.xml will lead as well to java.lang.OutOfMemoryError.

The match for this can be found in dataModel.xmap:
<!-- navigation for the current request -->
      <map:match pattern="*.navigation.xml">
        <map:aggregate element="navigation">
          <map:part src="cocoon:/tab-{1}.html" element="tab" />
          <map:part src="cocoon:/menu-{1}.html" element="menu" />
        </map:aggregate>
        <map:serialize />
      </map:match>

[Thorsten Scherler]

I solved this issue for the dispatcher by rewritting the menu and tab implementation (see subversion commit).

The first comment from David regarding that skins as well fail sometimes is based on the way the intermediate format for menu and tab is called. In all core sitemaps you can find something like:
....
 <map:transform type="linkrewriter" src="cocoon:/{1}linkmap-{2}.html"/>
...

The trailing ".html" leads in some cases to a loop because it will match as well *.html in other pipelines.

fixed in the new dispatcher