|
Nicola Ken Barozzi made changes - 16/Sep/04 11:24 AM
Nicola Ken Barozzi made changes - 16/Sep/04 11:24 AM
Nicola Ken Barozzi made changes - 16/Sep/04 02:11 PM
Nicola Ken Barozzi made changes - 16/Sep/04 02:12 PM
Nicola Ken Barozzi made changes - 16/Sep/04 02:12 PM
Now that I know what this is about I can better describe it.
Nicola Ken Barozzi made changes - 16/Sep/04 02:16 PM
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. 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 Seems to be related to
Dave Brondsema made changes - 19/Feb/05 01:14 AM
David Crossley made changes - 16/Apr/05 06:08 AM
Changed the issue title and description to better reflect the real problem.
David Crossley made changes - 16/Apr/05 06:17 AM
David Crossley made changes - 16/Apr/05 07:43 AM
This issue was well-described in Issue
I can see a way to restore the original workaround and not have its side-effects.
The workaround for
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
The workaround using cli.xconf has been working nicely.
David Crossley made changes - 10/Dec/05 06:22 AM
David Crossley made changes - 02/May/06 02:06 PM
David Crossley made changes - 02/May/06 02:06 PM
David Crossley made changes - 02/May/06 02:08 PM
David Crossley made changes - 02/May/06 04:05 PM
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.
David Crossley made changes - 02/May/06 04:10 PM
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Does not need to be solved for 0.6 anymore.