Project

Profile

Help

resolve document uri in doc() function

Added by Anonymous over 18 years ago

Legacy ID: #3410513 Legacy Poster: Brian Bailey (bpbailey)

I am new to the Saxon product and xquery in general. I am creating a Java method in a servlet that accepts an xquery expression as a request parameter and then executes that xquery. It is expected that the caller will use the doc() function in the expression to load one or more documents. When I call this servlet with an expression of "doc('books.xml')", I am getting a FileNotFoundException: D:\java_utils\jakarta-tomcat-5.0.28\bin\books.xml How do I tell Saxon that it should look at my classpath to find the documents? My relevant code from the servlet: Properties props = new Properties(); props.setProperty(OutputKeys.METHOD, "xml"); props.setProperty(OutputKeys.INDENT, "yes"); props.setProperty(OutputKeys.OMIT_XML_DECLARATION, "yes"); String xq = request.getParameter("xq"); Configuration config = new Configuration(); StaticQueryContext staticContext = new StaticQueryContext(config); XQueryExpression xqe = staticContext.compileQuery(xq); DynamicQueryContext dynamicContext = new DynamicQueryContext(config); ByteArrayOutputStream out = new ByteArrayOutputStream(); xqe.run(dynamicContext, new StreamResult(out), props);


Replies (7)

Please register to reply

RE: resolve document uri in doc() function - Added by Anonymous over 18 years ago

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

The first point about this kind of environment is that you need to be very careful about security. Unless you disable it, the incoming query can call arbitrary methods in the Java class library and thus has full privileges to do what it likes to your machine. There's a configuration option to disable calls on extension functions: make sure it's set. Second point: doc() resolves a relative URI against the base URI of the query. If you load the query from a file or an HTTP URI, this will be the file containing the query text. If you load it from a string as in your example, it will be the current directory under which the servlet code is running. But you can set the base URI to anything you like using the setBaseURI() method on the StaticQueryContext object. However, I don't think it's possible to set a base URI that will cause the classpath to be searched. To achieve that, I think you need to write and register your own URIResolver. I'd suggest setting the base URI to something like "classpath://local/". Then in your URIResolver, test whether this is the base URI, and if so, do the classpath search and return a reference to the resulting document. Writing a URI resolver also enables you to intercept any mischievous use of the doc() function with a file:// URI. You should also intercept calls on collection() with a CollectionURIResolver. Michael Kay Saxonica

RE: resolve document uri in doc() function - Added by Anonymous over 17 years ago

Legacy ID: #4095689 Legacy Poster: David Morales (dmoralesdf)

I have a related cuestion.... I'm working with a lot of xsl files that are inside a jar. Includes are like <xsl:include href="jar:file:c:/abs_path/library_xsl.jar!/one.xsl" /> But i don't want to write absolute paths, since it can changes, obviously... I try to write my own implementation of URIResolver, but it doesn't works because saxon doesn't compile stylesheet (if i write relative paths) I try to specify systemID in Source declaration, but it doesn't works because file protocol in import searchs in base URL... How can i work with classpath protocol? Could i write something like <xsl:include href="jar:classpath:library_xsl.jar!/one.xsl" /> ?? Can i specify in java code something to avoid this?? Thanks in advance...

RE: resolve document uri in doc() function - Added by Anonymous over 17 years ago

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

All I can say really is that (a) Saxon relies entirely on the java.net.URI and java.net.URL classes for dereferencing URIs (b) I'm no expert on what Java does and doesn't allow with jar: URIs. If something doesn't work, then I need to know precisely what you were doing and precisely how it failed.

RE: resolve document uri in doc() function - Added by Anonymous over 17 years ago

Legacy ID: #4095782 Legacy Poster: David Morales (dmoralesdf)

I think it isn't related to saxon, as the problem is how to write a <xsl:include> that uses a jar in the classpath... but i don't know if there is a java workaround... --> XSL IMPORT I want to import a file (one.xsl) that is inside a jar: 1. <xsl:include href="/folder/one.xsl" /> Doesn't works, obviously. 2. jar protocol need a URI, so <xsl:include href="jar:file:c:/abs_path/library_xsl.jar!/folder/one.xsl" /> works. But i dont't want to use absolute paths (it can changes) and jar is in the classpath... Then, -- Can i use classpath:// protocol?? (i tried it but it's a MalformedURL in xsl compilation) -- Can i set a base uri?? i mean, make include from relative path. Something like <xsl:include href="jar:file:/library_xsl.jar!/folder/one.xsl" /> that it can search in the classpath. Anyway, the big problem is that i can't use URIResolver as saxon can't compile the stylesheet... Thanks in advance... (i'm sorry for my english...)

RE: resolve document uri in doc() function - Added by Anonymous over 17 years ago

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

I really don't know what you mean by this statement: >Anyway, the big problem is that i can't use URIResolver as saxon can't compile the stylesheet I suspect you are misunderstanding some error message. If you told us what you actually did and what the error message actually said, then it would be possible to help you.

RE: resolve document uri in doc() function - Added by Anonymous over 17 years ago

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

I've done some poking around the "jar:" URI scheme. It seems that the java.net.URI class cannot resolve relative URIs relative to a base URI that uses this scheme; this is because the syntax that SUN chose unfortunately doesn't conform to the proper RFC syntax for a hierarchic URI, and when they implemented java.net.URI they stuck closely to the RFC. However, the older java.net.URL class can resolve the URI. So if you write your URIResolver like this: if (base != null && base.startsWith("jar:")) { try { URL baseURL = new URL(base); URL absoluteURL = new URL(baseURL, href); URI uri = absoluteURL.toURI(); } catch (MalformedURLException err) { throw new DynamicError("Invalid URI " + Err.wrap(relativeURI) + " - base " + Err.wrap(base), err); } catch (URISyntaxException err) { throw new DynamicError("Invalid URI " + Err.wrap(relativeURI) + " - base " + Err.wrap(base), err); } SAXSource source = new SAXSource(); ((SAXSource)source).setInputSource(new InputSource(url.toString())); source.setSystemId(url.toString()); return source; then it should work. I've got mixed feelings about including this in the standard URI resolver. The jar scheme looks pretty noncompliant with web standards, as far as I can tell (it's not even a registered URI scheme). I'll think about it.

RE: resolve document uri in doc() function - Added by Anonymous over 17 years ago

Legacy ID: #4097458 Legacy Poster: David Morales (dmoralesdf)

First of all, thanks for your help.... it seems that i were confused with relative and absolute paths, because solution were so easy as... <xsl:include href="jar:file:relative_folder/f_xsl.jar!/foo/var.xsl" /> Where relative_folder is under project's root folder... that is the xsl's base root as i can see... This solution doesn't need URIResolver or systemID in Source. And I'm getting the main stylesheet with StreamSource strSource = new StreamSource(this.getClass().getResourceAsStream("/foo/one.xsl")); The problem before was that saxon couldn't compile stylesheet so it didn't continue... i mean, i couldn't use my own URIResolver, for example.... Now, stylesheet compiles (it can resolve the include) and i can do transformations... Thanks again. And good work....

    (1-7/7)

    Please register to reply