cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject Re: A bug in XPath Directory Generator?
Date Wed, 21 Jan 2004 11:09:57 GMT
On 21.01.2004 07:26, Markus Vaterlaus wrote:
> Hi Joerg, hi list,
> the output of the stylesheet lokks like that:
>         <item key="version.xerces2">Xerces-J 2.4.0</item>
>         <item key="version.xalan2_2">Xalan Java 2.5.0</item>
>         <item key="java.version">1.4.1_02</item>
> Do you see any conflicts or potential problems?

Unfortunately not :) The above is ok as with JDK 1.4.1 you would have 
Xalan 2.2.D11 and with 1.4.2 Xalan 2.4. So the above shows that you are 
using the expected XML libraries in TOMCAT/common/endorsed.

Now I don't know exactly how to go on with your problem. The behaviour 
points to problems with SAX events, so having a look at the output of 
the log transformer after the xpath directory generator might give some 
hints. If it is really the XDG that has a bug or if you want to just 
test it, you can also try the normal DG and include the files via 


> On 20.01.2004 00:54, Joerg Heinicke wrote:
>>> Hello all,
>>> today I encountered a strange behaviour in the XPath Directory  
>>> Generator.  I was using it on a directory with about 600 files. If I  
>>> was specifying the attribute value for the parameter xpath as root  
>>> ("/", see below), the generated output could only be processed by  
>>> cocoon in a transformer generating an html page.
>>> ...
>>> <map:generate type="xpathdirectory" src="content">
>>>   <map:parameter name="xpath" value="/"/>
>>>   <map:parameter name="xmlFiles" value="\.x.*$"/>
>>> </map:generate>
>>> ...
>>> Using the same generator with an other matcher to generate a PDF did  
>>> not work: An error message was shown, stating that "fo:flow needs  
>>> block level children". However, using content view, manually saving  
>>> the resulting file and transforming it worked. After quite a while I  
>>> changed the value of xpath from "/" to "/therootelement" and  
>>> everything worked fine. Is there a bug in the xpath directory  
>>> generator or am I doing something wrong?
>> Such behaviour often points to problem with the XML libraries. What  
>> does the environment check say? Try the stylesheet at  
>> Joerg

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message