Olivier Billard wrote: > > For some of our pipelines, we don't use the cocoon protocol, > but just a serverpages generator. Renaming a variable in the > XSP to cause a "Language Exception" page, I still have the > content of the coplet empty (but as before the decoration > remains : <title>My title</title>). And I still have the > "correct" error display when calling directly the coplet pipeline. > > I added > <attribute> > <name>error-uri</name> > <value > xsi:type="java:java.lang.String" > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>cocoon:/ > erreur-coplet</value> > </attribute> > > in the profiles/copletdata/portal.xml in my coplet and added > a match in the sitemap, in the very beginning to avoid > */**-like matchings : > > <map:match pattern="erreur-coplet"> > <map:generate type="notifying"/> > <map:transform src="stylesheets/system/error2html.xslt"> > <map:parameter name="contextPath" > value="{request:contextPath}"/> > <map:parameter name="pageTitle" value="Resource not found"/> > </map:transform> > </map:match> > > but I have the same result : the content of the coplet is > void, and it seems that this pipeline is never called. > You can't use the "notifying" generator there as this is a new pipeline call (internally). So you can e.g. use the file generator reading a standard error.xml or something like that. > But it's right that the portal uses the cocoon protocol to > aggregate the various coplet contents. But why doesn't it > detect map:handle-errors branchings ? > That's how the cocoon: protocol was designed :) (So, again has nothing to do with the portal). Now, I'm not sure, but it might be possible to change the code of the portal coplet adapter, so that it passes the exception into the error pipeline so that you can use the "notifying" generator. Might be possible.
Carsten
