You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Bruno Dumon <br...@outerthought.org> on 2004/08/01 00:01:42 UTC
RE: Error: The Saxon DOM cannot be updated
On Sat, 2004-07-31 at 23:37, Lars Huttar wrote:
> I've managed to get Saxon working with Cocoon 2.1.5 under Jetty,
> but for the sake of our development server it would be really nice
> to have it working under 2.1.2 and Tomcat.
>
> The problem there, as described below, was that if I followed the
> Saxon transform with a source writer transform, an error is declared
> that says the Saxon DOM cannot be updated. This happens even
> though there is an intervening Xalan transform between the
> Saxon transform and the source writer transform:
>
> <map:match pattern="test-name-index/*/*/*">
> <map:generate src="sources/Language-name-index{3}.xml" label="raw" />
> <map:transform src="transforms/name-index-step1-xsl{2}.xsl" type="xslt-saxon" label="raw1"
> />
> <map:transform src="transforms/add-source-write.xsl" label="raw2" type="xslt">
> <map:parameter name="output-file" value="Language-name-index{3}-grouped.xml" />
> </map:transform>
> <map:transform type="write-source" />
> <map:serialize type="xml" />
> </map:match>
>
> I found more illuminating stuff in the error log than what I included
> in my first message on this topic. Note the lines after "Caused by":
>
> FATAL_E (2004-07-31) 16:14.24:114 [core.xslt-processor]
> (/cvsmount/ethnologue/test-name-index/xslt-saxon/1/Tiny) Thread-10/TraxErrorHandler: Error in
> TraxTransformer:
> file:/C:/Program%20Files/Apache%20Group/Tomcat%204.1/./../cocoon/./cvsmount/ethnologue/transforms/a
> dd-source-write.xsl; Line 12; Column 24;
> ; SystemID:
> file:/C:/Program%20Files/Apache%20Group/Tomcat%204.1/./../cocoon/./cvsmount/ethnologue/transforms/a
> dd-source-write.xsl; Line#: 12; Column#: 24
> javax.xml.transform.TransformerException: java.lang.UnsupportedOperationException: The Saxon DOM
> cannot be updated
> at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2341)
> at org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.java:682)
> ...
> ...
> Caused by: java.lang.UnsupportedOperationException: The Saxon DOM cannot be updated
> at net.sf.saxon.om.AbstractNode.disallowUpdate(AbstractNode.java:679)
> at net.sf.saxon.om.AbstractNode.removeChild(AbstractNode.java:566)
> at
> org.apache.cocoon.transformation.AbstractSAXTransformer.endRecording(AbstractSAXTransformer.java:48
> 6)
> at
> org.apache.cocoon.transformation.SourceWritingTransformer.endTransformingElement(SourceWritingTrans
> former.java:522)
> at
> org.apache.cocoon.transformation.AbstractSAXTransformer.endElement(AbstractSAXTransformer.java:358)
> at org.apache.cocoon.components.sax.XMLTeePipe.endElement(XMLTeePipe.java:124)
> at org.apache.xml.serializer.ToXMLSAXHandler.endElement(ToXMLSAXHandler.java:262)
> at org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.java:707)
> at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2336)
>
> It looks like the AbstractSAXTransformer's endRecording method
> is trying to remove a child node from the tree, and Saxon's
> AbstractNode class is crying foul.
>
> Can anyone suggest an approach for working around this problem?
> I suppose this is a bug in SourceWritingTransformer or
> AbstractSAXTransformer that has been fixed since Cocoon 2.1.2,
> since I'm using the same Saxon .jar file with Cocoon 2.1.5
> and not encountering this error.
I don't think there's a difference between those two cocoon versions to
explain it, rather the classloader which accidentely orders the jars
differently (there is no guarantee that the jars are read in
alphabetical order, this depends on the platform).
As the error message says, the Saxon DOM cannot be updated, meaning that
Saxon builds read-only DOM trees. Cocoon relies on the XSLT processor to
build DOM trees from SAX events. The XSLT processor that gets used for
this is the default one, as determined by information read from the
classpath resource
META-INF/services/javax.xml.transform.TransformerFactory.
A number of solutions that come to mind:
* delete the directory META-INF/services from the saxon jar
* put xalan in the endorsed lib directory, but saxon not (thus in the
normal WEB-INF/lib)
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Error: The Saxon DOM cannot be updated
Posted by Bruno Dumon <br...@outerthought.org>.
On Sun, 2004-08-01 at 10:57, Lars Huttar wrote:
> > -----Original Message-----
> > From: Bruno Dumon [mailto:bruno@outerthought.org]
> > Sent: Saturday, July 31, 2004 5:02 PM
> > To: users@cocoon.apache.org
> > Subject: RE: Error: The Saxon DOM cannot be updated
> >
> >
> > > It looks like the AbstractSAXTransformer's endRecording method
> > > is trying to remove a child node from the tree, and Saxon's
> > > AbstractNode class is crying foul.
> > >
> > > Can anyone suggest an approach for working around this problem?
> > > I suppose this is a bug in SourceWritingTransformer or
> > > AbstractSAXTransformer that has been fixed since Cocoon 2.1.2,
> > > since I'm using the same Saxon .jar file with Cocoon 2.1.5
> > > and not encountering this error.
> >
> > I don't think there's a difference between those two cocoon
> > versions to
> > explain it, rather the classloader which accidentely orders the jars
> > differently (there is no guarantee that the jars are read in
> > alphabetical order, this depends on the platform).
> >
> > As the error message says, the Saxon DOM cannot be updated,
> > meaning that
> > Saxon builds read-only DOM trees. Cocoon relies on the XSLT
> > processor to
> > build DOM trees from SAX events. The XSLT processor that gets used for
> > this is the default one, as determined by information read from the
> > classpath resource
> > META-INF/services/javax.xml.transform.TransformerFactory.
>
> Thanks Bruno, that is helpful.
> I move incrementally toward understanding how all this works.
>
> The above raises the question, though, if the classloader orders
> the jars differently between Cocoon 2.1.2 and 2.1.5, both under
> the same Tomcat installation, and it does so consistently...
> that would seem to imply a significant difference between something
> in Cocoon 2.1.2 and 2.1.5. Still, I see what you're saying, if there
> is no guarantee about the order in which jars are read, then there's
> little point in trying to fix the problem by means which aren't guaranteed
> to work.
It depends on the platform, on Windows, they are always alphabetically
sorted, so if you're using Windows, there must be another explanation.
I assume you're using the same application in both situations, thus both
with the SourceWritingTransformer in the pipeline? In that case it's
probably something in the implementation of that transformer that
changed.
>
> > A number of solutions that come to mind:
> > * delete the directory META-INF/services from the saxon jar
> > * put xalan in the endorsed lib directory, but saxon not (thus in the
> > normal WEB-INF/lib)
>
> This was already the case, at least, xalan was in the
> Tomcat 4.1/common/endorsed directory, but saxon was in
> Tomcat 4.1/common/lib. (There is not an endorsed directory
> in the Cocoon 2.1.2 installation I have that runs under
> Tomcat...)
>
> I tried moving saxon7.jar to cocoon/WEB-INF/lib.
> For Cocoon 2.1.5, this broke what had been working.
> (I.e. the transformation I described started giving the
> "Saxon DOM cannot be updated" error.)
> For Cocoon 2.1.2, it did not change the already-not-working
> behavior.
Ah, it might be that the endorsed jars override mechanism only works for
classes, not for other resources.
>
> I then tried deleting META-INF/services from saxon7.jar
> (in Cocoon 2.1.2).
> This worked!!
> Thank you!!
>
> I don't really understand why this works though; so here's
> hoping that this solution will continue to work.
>
> Thanks again!
>
> Lars
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Error: The Saxon DOM cannot be updated
Posted by Lars Huttar <la...@sil.org>.
> -----Original Message-----
> From: Bruno Dumon [mailto:bruno@outerthought.org]
> Sent: Saturday, July 31, 2004 5:02 PM
> To: users@cocoon.apache.org
> Subject: RE: Error: The Saxon DOM cannot be updated
>
>
> > It looks like the AbstractSAXTransformer's endRecording method
> > is trying to remove a child node from the tree, and Saxon's
> > AbstractNode class is crying foul.
> >
> > Can anyone suggest an approach for working around this problem?
> > I suppose this is a bug in SourceWritingTransformer or
> > AbstractSAXTransformer that has been fixed since Cocoon 2.1.2,
> > since I'm using the same Saxon .jar file with Cocoon 2.1.5
> > and not encountering this error.
>
> I don't think there's a difference between those two cocoon
> versions to
> explain it, rather the classloader which accidentely orders the jars
> differently (there is no guarantee that the jars are read in
> alphabetical order, this depends on the platform).
>
> As the error message says, the Saxon DOM cannot be updated,
> meaning that
> Saxon builds read-only DOM trees. Cocoon relies on the XSLT
> processor to
> build DOM trees from SAX events. The XSLT processor that gets used for
> this is the default one, as determined by information read from the
> classpath resource
> META-INF/services/javax.xml.transform.TransformerFactory.
Thanks Bruno, that is helpful.
I move incrementally toward understanding how all this works.
The above raises the question, though, if the classloader orders
the jars differently between Cocoon 2.1.2 and 2.1.5, both under
the same Tomcat installation, and it does so consistently...
that would seem to imply a significant difference between something
in Cocoon 2.1.2 and 2.1.5. Still, I see what you're saying, if there
is no guarantee about the order in which jars are read, then there's
little point in trying to fix the problem by means which aren't guaranteed
to work.
> A number of solutions that come to mind:
> * delete the directory META-INF/services from the saxon jar
> * put xalan in the endorsed lib directory, but saxon not (thus in the
> normal WEB-INF/lib)
This was already the case, at least, xalan was in the
Tomcat 4.1/common/endorsed directory, but saxon was in
Tomcat 4.1/common/lib. (There is not an endorsed directory
in the Cocoon 2.1.2 installation I have that runs under
Tomcat...)
I tried moving saxon7.jar to cocoon/WEB-INF/lib.
For Cocoon 2.1.5, this broke what had been working.
(I.e. the transformation I described started giving the
"Saxon DOM cannot be updated" error.)
For Cocoon 2.1.2, it did not change the already-not-working
behavior.
I then tried deleting META-INF/services from saxon7.jar
(in Cocoon 2.1.2).
This worked!!
Thank you!!
I don't really understand why this works though; so here's
hoping that this solution will continue to work.
Thanks again!
Lars
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org