DO NOT REPLY [Bug 10208] New: - [PATCH]/[RT] Aggregation and Error Conditions (file not found)

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10208>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10208

[PATCH]/[RT] Aggregation and Error Conditions (file not found)

           Summary: [PATCH]/[RT] Aggregation and Error Conditions (file not
                    found)
           Product: Cocoon 2
           Version: Current CVS
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: sitemap components
        AssignedTo: cocoon-dev@xml.apache.org
        ReportedBy: frank.ridderbusch@gmx.de


I am wondering, whether an option for an alternate error processing  
in aggregation would be useful. 
 
I'm typically using a sitemap setup like the following. The sidebar.xml file 
contains navigational information. 
 
     <map:match pattern="**/*"> 
        <map:aggregate element="page"> 
          <map:part src="{1}/{2}.xml"/> 
          <map:part element="sidebar" src="{1}/sidebar.xml"/> 
        </map:aggregate> 
     .... 
 
Some CVS heads ago, I would receive an exception on the browser, when 
sidebar.xml was not available. Now the exception only shows up in the
log files. However there is a noticable delay durin the exception handling. 

Well, I've poked in the sources and have created this little patch 
(attached) to ContentAggregator.java. This patch basically does 
the following: 
 
- If the aggregated part is a file 
  - if it exists, aggregate it 
  - if it does not exist, create a error element in the form 
 
    <aggregation-error>file <....> not found</aggregation-error> 
 
- if the aggregated part is not a file                                   
  go on a usual. 

I'm currently using it in connection with the DirectoryGenerator
and for the above mentioned navigational information. I now have 
the choice at the user level to react or not to. So far I'm quite 
happy with the patch.

The question, which remains, if this behaviour should be configurable
from the sitemap.

I've tried this on cocoon users, but haven't received any response.

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org