Re: cocoon:// protocol and map:mount
Gianugo Rabellino wrote:
OK, I'm doing something highly unortodox but believe me, I have a good
reason for it. :-)
The application we're developing ATM could really use some dynamic
generation of sitemaps (no, I'm not talking about
dynamic-per-request-and-conditional stuff: what I need is a sort of
macro system generating a whole sitemap out of a very simplified
configuration file). However, if I try this:
map:match pattern=mymaps/**
map:mount src=cocoon:/generate-mymaps-sitemap/{1}
uri-prefix=mymaps/{1} check-reloads=true/
/map:match
Mounting a sitemap also means changing the base used for relative URIs.
So you may be able to load the sitemap (and we can consider it to be a
bug it this fails), but the generated sitemap should use absolute URIs
or you'll have very strange results...
Sylvain
PS: this is check-reload with no 's', and the typo shows how useless
this attribute is ;-)
--
Sylvain WallezAnyware Technologies
http://apache.org/~sylvainhttp://anyware-tech.com
Apache Software Foundation Member Research Technology Director
Re: cocoon:// protocol and map:mount
On Mon, 21 Mar 2005 13:49:20 +0100, Carsten Ziegeler
[EMAIL PROTECTED] wrote:
Gianugo Rabellino wrote:
OK, I'm doing something highly unortodox but believe me, I have a good
reason for it. :-)
The application we're developing ATM could really use some dynamic
generation of sitemaps (no, I'm not talking about
dynamic-per-request-and-conditional stuff: what I need is a sort of
macro system generating a whole sitemap out of a very simplified
configuration file). However, if I try this:
map:match pattern=mymaps/**
map:mount src=cocoon:/generate-mymaps-sitemap/{1}
uri-prefix=mymaps/{1} check-reloads=true/
/map:match
I'm hit by a of java.lang.StackOverflowError, with some bus errors(!)
Any pointers on where to start looking?
Hmm, I know that this worked as we used it as well in some rare cases...
Did you try using an absolute path (cocoon://...) ?
Actually no, I used cocoon:/. However, changing it with cocoon://
causes a SourceNotFoundException, with Cocoon seemingly using a
file:// URL to resolve the inputstream, which is even weirder... does
it rely on SourceResolver at all?
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance: http://www.orixo.com
(blogging at http://www.rabellino.it/blog/)
Re: cocoon:// protocol and map:mount
Le 21 mars 05, à 12:57, Gianugo Rabellino a écrit :
map:mount src=cocoon:/generate-mymaps-sitemap/{1}
In a pinch, using http: instead of cocoon: might work...
(did anybody say hack? ;-)
-Bertrand
smime.p7s
Description: S/MIME cryptographic signature
Re: cocoon:// protocol and map:mount
Gianugo Rabellino wrote: Actually no, I used cocoon:/. However, changing it with cocoon:// causes a SourceNotFoundException, with Cocoon seemingly using a file:// URL to resolve the inputstream, which is even weirder... does it rely on SourceResolver at all? Yes, it does :( - hmm, so this is really a bug. Can you file it to bugzilla, so it doesn't get lost? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
RE: cocoon:// protocol and map:mount
Maybe you're using a file://... source in one of the generator/transformer components behind the pipeline? And maybe a little bit off-topic, but from a CRON job (CRON thread), the cocoon:// source resolving is extremely slow and causes OutOfMemory errors (in my use-case, I used the cocoon:/ source for generating personal mails for each individual user in our system). Bart. -Original Message- From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] Sent: Monday, March 21, 2005 4:04 PM To: dev@cocoon.apache.org Subject: Re: cocoon:// protocol and map:mount Gianugo Rabellino wrote: Actually no, I used cocoon:/. However, changing it with cocoon:// causes a SourceNotFoundException, with Cocoon seemingly using a file:// URL to resolve the inputstream, which is even weirder... does it rely on SourceResolver at all? Yes, it does :( - hmm, so this is really a bug. Can you file it to bugzilla, so it doesn't get lost? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
