cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <br...@outerthought.org>
Subject RE: Error: The Saxon DOM cannot be updated
Date Sun, 01 Aug 2004 10:19:14 GMT
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


Mime
View raw message