cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrzej Jan Taramina" <>
Subject Bug in SessionAttributeGenerator?
Date Tue, 07 Oct 2003 14:41:47 GMT
I ran into what seems to be the infamous "failed to execute pipeline" problem 
with Cocoon 2.1.2 in trying to execute a simple XSLT transform.  

Eliminating the transform from the pipeline and serializing directly to XML 
showed well formed XML going into the transform step, which was very 
frustrating, so I put in a logging transform. Lo and behold, the logger 
showed that the startDocument and endDocument SAX events were doubled up!

What caused this problem is that I had set a session attribute to hold the 
XML document I wanted transformed, but I had set that attribute to be the DOM 
Document object, then used SessionAttributeGenerator to create the SAX event 
stream for the transformation.  This should be perfectly acceptable!

Problem is that the generate() method in SessionAttributeGenerator looks as 

public void generate() throws IOException, SAXException, ProcessingException 

	if (this.elementName != null) {
		xmlConsumer.startElement("", this.elementName, this.elementName, new 
		XMLUtils.valueOf(xmlConsumer, this.attrObject);
		xmlConsumer.endElement("", this.elementName, this.elementName);
	} else {
		XMLUtils.valueOf(xmlConsumer, this.attrObject);

The bug is evident because if the this.attrObject is set to a Document object 
(rather than the document root Element), the method generates a start/end 
document....but so does the interior code! So you get duplicate 
start/endDocument events generated and downstream XSLT transforms barf on the 
input (funny that the XML serializer doesn't much care about this 

Anyway, rewriting the generate() method of SessionAttributeGenerator will 
correct this insidious bug:

public void generate() throws IOException, SAXException, ProcessingException 
	if( !( attrObject instanceof Document ) {

	...same interior code as before
	if( !( attrObject instanceof Document ) {

Of course, also need to add:

	import org.w3c.dom.Document;

Can one of the developers make this change for 2.1.3 and thus kill this bug 
once and for all?

Thanks guys!

Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions

View raw message