forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: [headsup] recent change in broken link handling
Date Fri, 06 Apr 2007 22:31:21 GMT
Thorsten Scherler wrote:
> On Fri, 2007-04-06 at 21:51 +1000, David Crossley wrote:
>> Ross Gardler wrote:
>>> David Crossley wrote:
>>>> The handling of broken site: links has recently changed.
>>>>
>>>> It used to report the link as BROKEN in the site build
>>>> and write its details to the broken-links.xml file.
>>>>
>>>> Now it generates a file called error_site_$linkname
>>>> with the "No pipeline matched request:" info inside it.
>>>>
>>>> I wonder if it is related to the recent change in
>>>> error handling for the locationmap.
>>> I think it probably is a side effect of the error handling. And not (in 
>>> its current form) a good one.
>> Note for the archives: See FOR-701 and r521063.
> 
> Thanks for this info David!
> ...
> <map:when test="resourceNotFound">
> 
> That is the puppy. I ran into the broken link issue the other day and
> was surprised that my build was successful with 0 pages build.
> 
> Actually the resourceNotFound is the only exception we do not want to
> catch (see broken links). 
> 
> Meaning as quick fix to not loose the whole error handling nor broken
> links we need to catch all exception *except* resourceNotFound and
> change the resource not found exception in the lm to a specific
> locationMap exception. 
> 
> Than we get back the broken links and have a "nicer" error handling.
> 
> wdyt?

Unfortunately, it's not that simple. We can't spot when the locationmap 
returns null to the sitemap hence we can't trap this and throw a 
different exception from the locationmap. At least not with the current 
implementation.

The following is from memory of how Tim explained things - can't find 
the mails in the archive.

The locationmap returns a null if no entry is found. But the way the 
locationmap mounting works we have no way of knowing if there is another 
map to check after the current one. Hence we don't know when a null from 
a single locationmap means a null from all locationmaps.

Now, I'm sure this can be worked around. But it is a bank holiday here 
in the UK so don't expect me to find loads of time to address this, it's 
a family weekend. I post this for information in case someone else has time.

Ross

Mime
View raw message