Project

Profile

Help

Oddities with WebLogic and URIResolvers

Added by Anonymous almost 19 years ago

Legacy ID: #3527763 Legacy Poster: Brian Rodgers (bkrodgers)

I'm using Saxon in an app to be deployed on WebLogic 8.1 SP4. We package XSLs in the WAR file, which may be deployed either exploded or unexploded on Windows (for development) and Unix (for production). The XSL may have multiple layers of <xsl:import> or <xsl:include> calls. I'd been using saxon 8.4 but recently tried to update to 8.6.1 to be using the latest and greatest. Two issues: - With a WAR (unexploded) deployment on Windows, when I do getServletContext().getResouce("/WEB-INF/xsl/myxsl.xsl"), it returns a URL that looks like "zip:c:\program files\bea\myDomain\deploy\myapp.war!/WEB-INF/xsl/myxsl.xsl" With both 8.4 and 8.6.1, the StandardURIResolver doesn't work, because it uses URI.resolve(), which considers this an "opaque" URI because it is "zip:c:..." instead of "zip:/c:...". This "zip" protocol appears to be something BEA wrote. I'm not sure why they're not using the more standard "jar" protocol, but that might have the same issue since a jar url usually looks like "jar:file:...path...". I can work around this by writing my own URIResolver that instead of resolving urls with URI.resolve(), takes the file name off of base to get the base directory and adds the relative href to it. - New with 8.6.1, if my base URI has spaces in it, this causes saxon to choke any time it hits an xsl element that extends CollatingFunction. It looks like CollatingFunction now starts off by checking if the base URI throws an URISyntaxException. Now, I can escape spaces in the URI that ServletContext.getResource() returns easily enough. However, this "zip:" protocol that weblogic uses won't load the URL if it has "%20" instead of a space. This leaves me needing to do the following when I create a StreamSource, both when making the initial call to newTemplates() and in my URIResolver. I start by decoding any spaces in the URI ("%20" -> " "), creating a URL, calling openConnection(), creating a StreamSource off that InputStream, and then encode spaces in the URI (" " -> "%20") and set that as the systemId on the StreamSource. This wasn't necessary when I was using 8.4, and from a peek at the source, it looks like 8.6 added the check for base URI validity in CollatingFunction. I realize neither of these may be "bugs" in saxon per se, but instead quirks with how WebLogic is doing something. I've got workarounds for both issues, but I'm wondering if there's a better way to handle these, either with things on my end or in a future saxon version. Thanks! -Brian


Replies (1)

RE: Oddities with WebLogic and URIResolvers - Added by Anonymous almost 19 years ago

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

Some good questions here that will take some thinking about. First, note that some bugs in the area of CollatingFunction have been identified recently, see https://sourceforge.net/tracker/index.php?func=detail&amp;aid=1406154&amp;group_id=29872&amp;atid=397617 Secondly, over the last few months the W3C specs have been changed so that they now uniformly say that whereever a URI is used (except where other specs say otherwise) an "unescaped URI" (that is a string that would be a URI if escaped - what I sometimes call a wannabe-URI) should also be accepted. I think this should include the base URI (though it's not absolutely clear, since the URI resolution algorithms in the RFCs apply only to URIs that have been properly escaped). In any event, the specs have moved in the direction of tolerance in this area. However, I'm not sure that even the more tolerant definition of URIs allows a string containing backslashes. I think that CollatingFunction shouldn't reject a bad base URI unless it actually needs to use it (to resolve a relative collation URI, which is a fairly rare event). So I'll think about how to make it less draconian, which should help - but it won't solve all the problems, I suspect. Michael Kay

    (1-1/1)

    Please register to reply