forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sjur Moshagen <>
Subject Re: FOPNGSerializer, user-config and locationmaps
Date Mon, 18 Aug 2008 11:34:18 GMT
>> To me it looks like the locationmap, when nothing is found, returns  
>> the path
>> to the locationmap.xml file (excluding the filename), combined with  
>> the last
>> part of the lm: specification in the sitemap: 'pdf.user-config}'
>> An empty locationmap selection:
>>   <match pattern="pdf.user-config">
>>     <select>
>>       <location src="resources/fonts/config.xml"/>
>>       <location src=""/>
>>     </select>
>>   </match>
>> returns the same bogus string as above.
>> Anybody any clue about what is going on? How can I get the intended
>> behaviour?
>> Sjur
>> [1]
> Hi Sjur,
> I mailed Cocoon about this[1] long ago and filed a bug[2] which says
> it's now fixed.  I reckon we'd need to update Cocoon to see if that's
> true(I don't see any actual commits against it).  I don't remember
> much more than that unfortunately but I hope that helps.
> --tim
> [1] -
> [2] -

I believe it is a locationmap problem - it is the locationmap that is  
returning the string, somehow. I have also tested the following in the  

     <map:serializers default="fo2pdf">
       <map:serializer name="fo2pdf"  
src="org.apache.cocoon.blocks.fop.FOPNGSerializer" mime- 

That is, with a completely *empty* <user-config> element. And this  
works - the FOPNGSerializer falls back to the defaults.

And I'm sorry: I didn't test well enough - the problem arises even  
thoug there IS a matching config file. So there seems to be a problem  
with my locationmap definition?

To sum up:

1. if the path is hardcoded in the sitemap, all is ok
2. if the path is empty in the sitemap, all is ok
3. if the path is looked up via lm, and a matching file is found(*),  
the path returned is garbage
4. if the path is looked up via lm, but no match is found, garbage is  
returned instead of the empty string

Both 3. and 4. returns:


(*) I don't *know* that the matching file is found, I'm just assuming  
here - how can I check that?

Thanks for the help,

View raw message