Cinclude crashing catalina...?

[Alexander Smirnoff <as...@vistar.ca>]

Hi,

I had weird JVM crash after using cinclude in my application. I spent 
a little time to investigate the issue and this what I figured out:

When I call <cinclude:include src="cocoon:/message"/> cinclude 
transformer does not rewrite the request's Servlet Path to "message".
For example In my sitemap I have next:

<map:match pattern="cinclude">
    <map:generate src="xml/cinclude.xml"/>
    <map:transform type="cinclude" label="include"/>
    <map:serialize type="xml"/>
</map:match>

<map:match pattern="message">
    <map:generate src="xsp/message.xsp" type="serverpages"/>
    <map:serialize type="xml"/>
</map:match>

xml/cinclude.xml has <cinclude:include src="cocoon:/message"/> 
in it.

This snippet is working properly, but something I do not understand:
If Servlet Path is not rewritten to "message", how sitemap properly 
picks the 'message' pipeline? Shoudn't it use the same 'cinclude'
pipeline again and again?

It has something to do with matcher or cocoon:/ protocol call. In my 
application I have my own implementation of the matcher which 
relies on getServletPath for match condition. And guess what happens 
when I use cinclude pipeline with this matcher? Right. It calls 
recursively itself in endless loop until all memory is exhausted and 
apparently crushes JVM...

So the question is - if request should not be rewriten in cocoon:/ call,
how to implement matcher so cinclude will correctly pickup the right
pipeline?

Thanks,
Alex.



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

RE: Cinclude crashing catalina...?

[Carsten Ziegeler <cz...@s-und-n.de>]

> -----Original Message-----
> From: Alexander Smirnoff [mailto:asmirnoff@vistar.ca]
> Sent: Thursday, August 15, 2002 4:08 PM
> To: cocoon-users@xml.apache.org
> Cc: cocoon-dev@xml.apache.org
> Subject: Cinclude crashing catalina...?
> 
> 
> Hi,
> 
> I had weird JVM crash after using cinclude in my application. I spent 
> a little time to investigate the issue and this what I figured out:
> 
> When I call <cinclude:include src="cocoon:/message"/> cinclude 
> transformer does not rewrite the request's Servlet Path to "message".
> For example In my sitemap I have next:
> 
> <map:match pattern="cinclude">
>     <map:generate src="xml/cinclude.xml"/>
>     <map:transform type="cinclude" label="include"/>
>     <map:serialize type="xml"/>
> </map:match>
> 
> <map:match pattern="message">
>     <map:generate src="xsp/message.xsp" type="serverpages"/>
>     <map:serialize type="xml"/>
> </map:match>
> 
> xml/cinclude.xml has <cinclude:include src="cocoon:/message"/> 
> in it.
> 
> This snippet is working properly, but something I do not understand:
> If Servlet Path is not rewritten to "message", how sitemap properly 
> picks the 'message' pipeline? Shoudn't it use the same 'cinclude'
> pipeline again and again?
> 
> It has something to do with matcher or cocoon:/ protocol call. In my 
> application I have my own implementation of the matcher which 
> relies on getServletPath for match condition. And guess what happens 
> when I use cinclude pipeline with this matcher? Right. It calls 
> recursively itself in endless loop until all memory is exhausted and 
> apparently crushes JVM...
> 
Yes, it's the cocoon: protocol doing the magic - your message pipeline
is called internally which means within the same request. In order
to get the information about the uri of the real request (cinclude) in
the internal pipeline, the getServletPath method returns this
original value.

> So the question is - if request should not be rewriten in cocoon:/ call,
> how to implement matcher so cinclude will correctly pickup the right
> pipeline?
> 
The getSitemapURI() method was added to the request object for exactly 
that purpose - use this whenever you want to compare the URI of the
request.

HTH
Carsten

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