Project

Profile

Help

XSLT file locked

Added by Anonymous about 16 years ago

Legacy ID: #4820925 Legacy Poster: Scott Colestock (scolestock)

I'm currently caching compilations of a stylesheet, using a caching library that allows me to specify the XSLT file itself as a cache dependency (i.e. if the file changes, the cache is invalidated.) However, I'm finding that the XsltCompiler (or something else within Saxon) is locking the XSLT file. So, I've taken to making a temporary copy of the file so the XSLT can remain updateable (i.e. I can copy fresh copies of the XSLT file up to the server.) I'd like to avoid this file copy though - is there a way to use the API such that the original file would not be locked? Scott Colestock


Replies (4)

Please register to reply

RE: XSLT file locked - Added by Anonymous about 16 years ago

Legacy ID: #4821134 Legacy Poster: Michael Kay (mhkay)

Unfortunately .NET is much more fussy than Java about closing input streams after use, so there have been a few problems of this kind. Please make sure you are using the latest version (9.0.0.3), because some of these problems have been fixed. To investigate this I need to know how you are supplying the stylesheet input to the XsltCompiler.

RE: XSLT file locked - Added by Anonymous about 16 years ago

Legacy ID: #4822642 Legacy Poster: Scott Colestock (scolestock)

Well, I was using xslt = compiler.Compile(new Uri(uri)).Load(); where the uri was something like "FILE://c:\somepath\somestyle.xsl" I moved to loading the stylesheet up into a DOM, and then using xslt = compiler.Compile(new XmlNodeReader(styleSheet)).Load(); as an interim solution (rather than using a temp copy of the file)

RE: XSLT file locked - Added by Anonymous about 16 years ago

Legacy ID: #4822981 Legacy Poster: Michael Kay (mhkay)

>uri was something like "FILE://c:\somepath\somestyle.xsl" That's not a URI - URIs don't contain backslashes. The .NET environment will probably let you get away with it, but one day you'll run into a Saxon interface that's stricter about the rules. However, that's nothing to do with the problem. I've established that Saxon is setting a flag that attempts to cause the input file to be closed after use, but the flag is getting lost in the course of a rather tortuous path. It would be nice if Compile(Uri) were a thin veneer on top of Compile(Stream), but unfortunately that's not the case, because of the need to call XmlResolvers and the like. So it's going to take a little bit of careful thought to find a solution. Michael Kay http://www.saxonica.com/

RE: XSLT file locked - Added by Anonymous about 16 years ago

Legacy ID: #4824591 Legacy Poster: Michael Kay (mhkay)

I've now fixed this, and tested the fix. However, it turned out to be surprisingly complicated, so I think the change is probably too risky for a patch - it needs to have the full test suite run against it before I'll be confident. So the fix will have to wait till the next development release. In the meantime, you can work around the problem by using Compile(XmlReader) and closing the stream yourself.

    (1-4/4)

    Please register to reply