You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Barry McMullin <mc...@eeng.dcu.ie> on 2002/09/17 13:39:18 UTC

aggregation and exception (404) handling - how to?

Hi -

I'm attempting to configure a simple "toy" site with cocoon
(2.0.3). I have a pipeline which delivers (almost) all pages by
aggregating a "content" xml file with a "navigation" xml file
(and doing a little transformation on the result).  This is
matched on almost every URI I get:

   <map:match pattern="**">
    <map:aggregate element="page" ns="http://eaccess.rince.ie/xmlns/local">
     <map:part src="template/site-nav.xml"/>
     <map:part src="content/{1}.xml"/>
    </map:aggregate>
    <map:transform src="xslt/page-layout-tables.xslt"/>
    <map:transform src="xslt/strip-xhtmlns.xslt"/>
    <map:serialize/>      
   </map:match>

My problem: because the pattern match is (deliberately) so broad,
this matches nonsense URIs - for which I would like to return a
"proper" 404 status.  But - apparently - if a <map:part> doesn't
generate any content (in this case because the corresponding file
does not exist) that does not raise any exception for the
pipeline as a whole.  So if I use a nonsense URI, instead of a
404 I get a page with an empty content part (and a normal
navigation part).

I have tried moving the reading of the content file into a
pipeline of its own (and using the "cocoon:" protocol in map:part
to get to it).  If I contrive to use that pipeline in isolation,
for a nonsense URL, I get a standard cocoon exception page
(albeit with a 500 status instead of 404); but when I use the
aggregating pipeline it still "silently" returns an empty content
page.

As far as I can see, <map-error-handler> is not relevant to this
(as it would only allow customisation of the error page - but I'm
not getting such a page at all?).

I have trawled both the docs and the mailing list, but without
finding any clear guide on what to do here (but I freely admit
I'm only slowly coming up to speed).  I can imagine a variety
of ways of fixing this; but I'm wondering is there a "preferred"
or "recommended" approach - it seems like a fairly general issue?

Thanks,

- Barry.

-- 



---------------------------------------------------------------------
Please check that your question  has not already been answered in the
FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail:     <co...@xml.apache.org>
For additional commands, e-mail:   <co...@xml.apache.org>


Re: aggregation and exception (404) handling - how to?

Posted by Vadim Gritsenko <va...@verizon.net>.
Barry McMullin wrote:

>On Tue, 17 Sep 2002, Antonio Gallardo Rivera wrote:
>
>  
>
>>You need the <map:handle-errors> element inside your pipeline, for example:
>>
>><map:handle-errors>
>>        <map:transform src="stylesheets/system/error2document.xsl"/>
>>        <map:transform src="stylesheets/apache.xsl"/>
>>        <map:serialize status-code="500"/>
>></map:handle-errors>
>>    
>>
>
>I don't *think* so ... but I am open to correction.
>
>The problem, as I see it, is that no exception or failure is
>being raised in the relevant <map:match> *at all* (in the case of
>doing an aggregation, and only one part is missing) - so there is
>nothing to trigger a <map:handle-errors>.
>
>But, for the record, I just added a degenerate:
>

In your case I would add:


>  <map:handle-errors type="404">
>   <map:serialize status-code="500"/>
>  </map:handle-errors>
>

(note @type).


>to the pipeline, and it makes no apparent difference to the behaviour.
>
>(As an aside: my understanding is that cocoon would only
>"automatically" generate a 404 status when no matcher is found
>for the URI at all - is that right?)
>

No. type="404" handler is used for any ResourceNotFoundException 
handling too (try throwing it in the action or among the first lines of 
XSP :)

Vadim


>Best,
>
>- Barry.
>  
>


---------------------------------------------------------------------
Please check that your question  has not already been answered in the
FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail:     <co...@xml.apache.org>
For additional commands, e-mail:   <co...@xml.apache.org>


Re: aggregation and exception (404) handling - how to?

Posted by Barry McMullin <mc...@eeng.dcu.ie>.
On Tue, 17 Sep 2002, Antonio Gallardo Rivera wrote:

> You need the <map:handle-errors> element inside your pipeline, for example:
> 
> <map:handle-errors>
>         <map:transform src="stylesheets/system/error2document.xsl"/>
>         <map:transform src="stylesheets/apache.xsl"/>
>         <map:serialize status-code="500"/>
> </map:handle-errors>

I don't *think* so ... but I am open to correction.

The problem, as I see it, is that no exception or failure is
being raised in the relevant <map:match> *at all* (in the case of
doing an aggregation, and only one part is missing) - so there is
nothing to trigger a <map:handle-errors>.

But, for the record, I just added a degenerate:

  <map:handle-errors>
   <map:serialize status-code="500"/>
  </map:handle-errors>

to the pipeline, and it makes no apparent difference to the behaviour.

(As an aside: my understanding is that cocoon would only
"automatically" generate a 404 status when no matcher is found
for the URI at all - is that right?)

Best,

- Barry.


---------------------------------------------------------------------
Please check that your question  has not already been answered in the
FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail:     <co...@xml.apache.org>
For additional commands, e-mail:   <co...@xml.apache.org>


Re: aggregation and exception (404) handling - how to?

Posted by Antonio Gallardo Rivera <ag...@agsoftware.dnsalias.com>.
El Martes, 17 de Septiembre de 2002 05:39, Barry McMullin escribió:
> Hi -
>
> I'm attempting to configure a simple "toy" site with cocoon
> (2.0.3). I have a pipeline which delivers (almost) all pages by
> aggregating a "content" xml file with a "navigation" xml file
> (and doing a little transformation on the result).  This is
> matched on almost every URI I get:
>
>    <map:match pattern="**">
>     <map:aggregate element="page" ns="http://eaccess.rince.ie/xmlns/local">
>      <map:part src="template/site-nav.xml"/>
>      <map:part src="content/{1}.xml"/>
>     </map:aggregate>
>     <map:transform src="xslt/page-layout-tables.xslt"/>
>     <map:transform src="xslt/strip-xhtmlns.xslt"/>
>     <map:serialize/>
>    </map:match>

You need the <map:handle-errors> element inside your pipeline, for example:

<map:handle-errors>
        <map:transform src="stylesheets/system/error2document.xsl"/>
        <map:transform src="stylesheets/apache.xsl"/>
        <map:serialize status-code="500"/>
</map:handle-errors>

Antonio Gallardo

>
> My problem: because the pattern match is (deliberately) so broad,
> this matches nonsense URIs - for which I would like to return a
> "proper" 404 status.  But - apparently - if a <map:part> doesn't
> generate any content (in this case because the corresponding file
> does not exist) that does not raise any exception for the
> pipeline as a whole.  So if I use a nonsense URI, instead of a
> 404 I get a page with an empty content part (and a normal
> navigation part).
>
> I have tried moving the reading of the content file into a
> pipeline of its own (and using the "cocoon:" protocol in map:part
> to get to it).  If I contrive to use that pipeline in isolation,
> for a nonsense URL, I get a standard cocoon exception page
> (albeit with a 500 status instead of 404); but when I use the
> aggregating pipeline it still "silently" returns an empty content
> page.
>
> As far as I can see, <map-error-handler> is not relevant to this
> (as it would only allow customisation of the error page - but I'm
> not getting such a page at all?).
>
> I have trawled both the docs and the mailing list, but without
> finding any clear guide on what to do here (but I freely admit
> I'm only slowly coming up to speed).  I can imagine a variety
> of ways of fixing this; but I'm wondering is there a "preferred"
> or "recommended" approach - it seems like a fairly general issue?
>
> Thanks,
>
> - Barry.

---------------------------------------------------------------------
Please check that your question  has not already been answered in the
FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail:     <co...@xml.apache.org>
For additional commands, e-mail:   <co...@xml.apache.org>


Re: aggregation and exception (404) handling - how to?

Posted by u15603 <u1...@hs-harz.de>.
u15603 schrieb:
> Hello Barry,
> 
> I think it is a known bug! You could find it in the buglist, with this 
> link:
> 
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12293
> 
> I hope that help you! :-)
> 
> Dirk
> 
> Barry McMullin schrieb:
> 
>> Hi -
>>
>> I'm attempting to configure a simple "toy" site with cocoon
>> (2.0.3). I have a pipeline which delivers (almost) all pages by
>> aggregating a "content" xml file with a "navigation" xml file
>> (and doing a little transformation on the result).  This is
>> matched on almost every URI I get:
>>
>>    <map:match pattern="**">
>>     <map:aggregate element="page" 
>> ns="http://eaccess.rince.ie/xmlns/local">
>>      <map:part src="template/site-nav.xml"/>
>>      <map:part src="content/{1}.xml"/>
>>     </map:aggregate>
>>     <map:transform src="xslt/page-layout-tables.xslt"/>
>>     <map:transform src="xslt/strip-xhtmlns.xslt"/>
>>     <map:serialize/>         </map:match>
>>
>> My problem: because the pattern match is (deliberately) so broad,
>> this matches nonsense URIs - for which I would like to return a
>> "proper" 404 status.  But - apparently - if a <map:part> doesn't
>> generate any content (in this case because the corresponding file
>> does not exist) that does not raise any exception for the
>> pipeline as a whole.  So if I use a nonsense URI, instead of a
>> 404 I get a page with an empty content part (and a normal
>> navigation part).
>>
>> I have tried moving the reading of the content file into a
>> pipeline of its own (and using the "cocoon:" protocol in map:part
>> to get to it).  If I contrive to use that pipeline in isolation,
>> for a nonsense URL, I get a standard cocoon exception page
>> (albeit with a 500 status instead of 404); but when I use the
>> aggregating pipeline it still "silently" returns an empty content
>> page.
>>
>> As far as I can see, <map-error-handler> is not relevant to this
>> (as it would only allow customisation of the error page - but I'm
>> not getting such a page at all?).
>>
>> I have trawled both the docs and the mailing list, but without
>> finding any clear guide on what to do here (but I freely admit
>> I'm only slowly coming up to speed).  I can imagine a variety
>> of ways of fixing this; but I'm wondering is there a "preferred"
>> or "recommended" approach - it seems like a fairly general issue?


therefore you could read the posting in the cocoon mailinglist under the 
reference "Nullpointer Exception - SessionTransformer" (04.09.2002)


>>
>> Thanks,
>>
>> - Barry.
>>
> 
> 
> 
> ---------------------------------------------------------------------
> Please check that your question  has not already been answered in the
> FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>
> 
> To unsubscribe, e-mail:     <co...@xml.apache.org>
> For additional commands, e-mail:   <co...@xml.apache.org>
> 
> 



---------------------------------------------------------------------
Please check that your question  has not already been answered in the
FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail:     <co...@xml.apache.org>
For additional commands, e-mail:   <co...@xml.apache.org>


Re: aggregation and exception (404) handling - how to?

Posted by u15603 <u1...@hs-harz.de>.
Barry McMullin schrieb:
> On Tue, 17 Sep 2002, u15603 wrote:
> 
> 
>>I think it is a known bug! You could find it in the buglist, with this link:
>>
>>http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12293
> 
> 
> Thanks Dirk -
> 
> I guess it would be comforting to feel that this is a cocoon
> "problem" (rather than just a problem of my own
> ignorance/incompetence in using cocoon)!
> 
> I have browsed the bug report; I don't know enough of the cocoon
> internals to really judge whether it is likely to be at the root
> of my issue.  In particular, it is not immediately apparent to me
> that the mechanisms mentioned in this bug report are (also)
> triggered in the implementation of aggregation.  Is there a
> knowledgable developer who can confirm that diagnosis (or maybe
> Dirk is already sure of that)?

therefore you could read the posting in the cocoon mailinglist under the 
reference "Nullpointer Exception - SessionTransformer" (04.09.2002

> 
> Thx,
> 
> - Barry.
> 
> 
> ---------------------------------------------------------------------
> Please check that your question  has not already been answered in the
> FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>
> 
> To unsubscribe, e-mail:     <co...@xml.apache.org>
> For additional commands, e-mail:   <co...@xml.apache.org>
> 
> 



---------------------------------------------------------------------
Please check that your question  has not already been answered in the
FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail:     <co...@xml.apache.org>
For additional commands, e-mail:   <co...@xml.apache.org>


Re: aggregation and exception (404) handling - how to?

Posted by Vadim Gritsenko <va...@verizon.net>.
Barry McMullin wrote:

>On Tue, 17 Sep 2002, u15603 wrote:
>
>  
>
>>I think it is a known bug! You could find it in the buglist, with this link:
>>
>>http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12293
>>    
>>
>
>Thanks Dirk -
>
>I guess it would be comforting to feel that this is a cocoon
>"problem" (rather than just a problem of my own
>ignorance/incompetence in using cocoon)!
>
>I have browsed the bug report; I don't know enough of the cocoon
>internals to really judge whether it is likely to be at the root
>of my issue.  In particular, it is not immediately apparent to me
>that the mechanisms mentioned in this bug report are (also)
>triggered in the implementation of aggregation.  Is there a
>knowledgable developer who can confirm that diagnosis (or maybe
>Dirk is already sure of that)?
>

I don't think these are related, but seems I found other issue - Cocoon 
reports 500 instead of 404 in my case... :-/

Vadim


>Thx,
>
>- Barry.
>  
>


---------------------------------------------------------------------
Please check that your question  has not already been answered in the
FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail:     <co...@xml.apache.org>
For additional commands, e-mail:   <co...@xml.apache.org>


Re: aggregation and exception (404) handling - how to?

Posted by Barry McMullin <mc...@eeng.dcu.ie>.
On Tue, 17 Sep 2002, u15603 wrote:

> I think it is a known bug! You could find it in the buglist, with this link:
> 
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12293

Thanks Dirk -

I guess it would be comforting to feel that this is a cocoon
"problem" (rather than just a problem of my own
ignorance/incompetence in using cocoon)!

I have browsed the bug report; I don't know enough of the cocoon
internals to really judge whether it is likely to be at the root
of my issue.  In particular, it is not immediately apparent to me
that the mechanisms mentioned in this bug report are (also)
triggered in the implementation of aggregation.  Is there a
knowledgable developer who can confirm that diagnosis (or maybe
Dirk is already sure of that)?

Thx,

- Barry.


---------------------------------------------------------------------
Please check that your question  has not already been answered in the
FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail:     <co...@xml.apache.org>
For additional commands, e-mail:   <co...@xml.apache.org>


Re: aggregation and exception (404) handling - how to?

Posted by u15603 <u1...@hs-harz.de>.
Hello Barry,

I think it is a known bug! You could find it in the buglist, with this link:

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

I hope that help you! :-)

Dirk

Barry McMullin schrieb:
> Hi -
> 
> I'm attempting to configure a simple "toy" site with cocoon
> (2.0.3). I have a pipeline which delivers (almost) all pages by
> aggregating a "content" xml file with a "navigation" xml file
> (and doing a little transformation on the result).  This is
> matched on almost every URI I get:
> 
>    <map:match pattern="**">
>     <map:aggregate element="page" ns="http://eaccess.rince.ie/xmlns/local">
>      <map:part src="template/site-nav.xml"/>
>      <map:part src="content/{1}.xml"/>
>     </map:aggregate>
>     <map:transform src="xslt/page-layout-tables.xslt"/>
>     <map:transform src="xslt/strip-xhtmlns.xslt"/>
>     <map:serialize/>      
>    </map:match>
> 
> My problem: because the pattern match is (deliberately) so broad,
> this matches nonsense URIs - for which I would like to return a
> "proper" 404 status.  But - apparently - if a <map:part> doesn't
> generate any content (in this case because the corresponding file
> does not exist) that does not raise any exception for the
> pipeline as a whole.  So if I use a nonsense URI, instead of a
> 404 I get a page with an empty content part (and a normal
> navigation part).
> 
> I have tried moving the reading of the content file into a
> pipeline of its own (and using the "cocoon:" protocol in map:part
> to get to it).  If I contrive to use that pipeline in isolation,
> for a nonsense URL, I get a standard cocoon exception page
> (albeit with a 500 status instead of 404); but when I use the
> aggregating pipeline it still "silently" returns an empty content
> page.
> 
> As far as I can see, <map-error-handler> is not relevant to this
> (as it would only allow customisation of the error page - but I'm
> not getting such a page at all?).
> 
> I have trawled both the docs and the mailing list, but without
> finding any clear guide on what to do here (but I freely admit
> I'm only slowly coming up to speed).  I can imagine a variety
> of ways of fixing this; but I'm wondering is there a "preferred"
> or "recommended" approach - it seems like a fairly general issue?
> 
> Thanks,
> 
> - Barry.
> 



---------------------------------------------------------------------
Please check that your question  has not already been answered in the
FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail:     <co...@xml.apache.org>
For additional commands, e-mail:   <co...@xml.apache.org>