Re: DOCBOOK-APPS: Sun Resolver Question

[Steffen Maier <Steffen dot Maier at studserv dot uni-stuttgart dot de>]

On Sat, Apr 20, 2002 at 04:44:23PM -0700, Eric Richardson wrote:
> Eric Richardson wrote:
> > I'm trying to get Ant to use the catalog code so I'm trying to pass a 
> > -D<resolver property-unknown>=com.sun.resolver.tools.CatalogResolver to 
> > ant. I traced the ant code and it passes the -D into the system 
> > properties so it should work if Xerces2 will use it internally.
> >
> > Is there a property I can set that will get the SAXReader to use the 
> > CatalogResolver in Xerces2?
> > 
> > The Sun resolver has the wrapper for xp and xt for the parser. I see 
> > there is a org.xml.sax.driver property, so is there a 
> > org.xml.sax.resolver property or a driver or something for xerces?
> 
> I dug into this pretty extensively but still don't understand it all. It 
> seems that there are three -D<name>=<value> that java understands. The 
> names are as follows.
> javax.xml.parsers.SAXParserFactory
> javax.xml.parsers.DocumentBuilderFactory
> org.xml.sax.parser
> 
> Passing one of these with the value of an appropriate class file should 
> force JAXP in the first two to use the passed in class file. Likewise 
> for the SAX parser. I have not tried this out yet.
> 
> I looked at the source code for ant and they do the following. First 
> they do a class.forName on the javax.xml.parsers.SAXParserFactory which 
> forces a SAXParserFactory class into memory if it is found. Later they 
> do SAXParserFactory.newInstance(). Later they use their own version of 
> an entity resolver so I don't think any attempts to use the resolver 
> will work with at least ant 1.4.1. I wanted internal subsets to use 
> Norm's entity resolver so shared properties and targets in ant could be 
> held in one location for the ease of maintainability.

Good news: it does work... somehow at least ;-)

> I still would like to know which class of the resolver would be 
> appropriate for the SAXParserFactory or if the new resolver code has to 
> be used at a lower level as used in Xalan. This question is for the 
> xerces2 parser as the documentation shows hoe for xp and xt.

Sorry for quoting your whole message but it's been awhile that I worked
through all that mess and I forgot a lot. So I base my reply on a private
mail I sent to one of the list member earlier this year.


At the moment it doesn't seem to be possible to force saxon to use the
catalog resolver when using ant's style task. Saxon provides command line
parameters but no java properties to configure a URIResolver, neither as
saxon extension nor through JAXP (which supports parsers and transformers
through java properties but no URIResolver, the latter would have to be
implemented through direct use of jaxp methods if I understood the spec
correctly).

Furthermore there were some issues concerning failing classpath and
disfunctional systemproperties within the style task:

search result:
http://marc.theaimsgroup.com/?l=ant-dev&w=2&r=1&s=saxon&q=b
selected postings:
http://marc.theaimsgroup.com/?l=ant-dev&m=100564428929226&w=2
http://marc.theaimsgroup.com/?l=ant-dev&m=100015372026767&w=2

(http://marc.theaimsgroup.com/?l=ant-user&w=2&r=1&s=docbook&q=b)

search result:
http://marc.theaimsgroup.com/?l=ant-user&w=2&r=1&s=saxon&q=b
selected postings:
http://marc.theaimsgroup.com/?l=ant-user&m=100478289007456&w=2
http://marc.theaimsgroup.com/?l=ant-user&m=99309341227134&w=2
http://marc.theaimsgroup.com/?l=ant-user&m=99245693820222&w=2

To overcome these problems I used a script to call ant. Theoretically not
all the parameters in there would be necessary, especially if one does
without the style task and only uses java tasks (where classpath and
systemproperties can be specified). The "." in classpath is for the file
CatalogManager.properties. Crimson.jar is not in the classpath because
ant.jar contains "Class-Path: jaxp.jar parser.jar crimson.jar optional.jar
xalan.jar", so crimson can be used for ...SAXParserFactory right away.

BTW, I just used crimson because saxon's parser aelfred had a bug when
resolving relative URIs which revealed as soon as one used the catalog
resolver instead of aelfred's default resolver. This was true for saxon
6.4.4 and might be fixed as of 6.5.

The other software I used was ant-1.4.1 as well as crimson and jaxp
packaged in Sun's java_xml_pack-fall01 and Norm's catalog resolver, of
course.

***<db:filename os="WinNT">b.bat</db:filename> (all in one line)***:

@REM     catalog       ;website-ext;db-extensions;saxon-itself;...
java -cp \
resolver.jar;.;saxon64.jar;saxon644.jar;saxon.jar;ant.jar;jaxp.jar \
 -Djavax.xml.transform.TransformerFactory=\
   com.icl.saxon.TransformerFactoryImpl \
 -Djavax.xml.parsers.SAXParserFactory=\
  org.apache.crimson.jaxp.SAXParserFactoryImpl \
 org.apache.tools.ant.Main %1 %2 %3 %4 %5 %6 %7 %8 %9

***<db:filename>build.xml</db:filename>***:

<project name="foo" default="test" basedir=".">
    ...
    <path id="classpath.saxon">
      <pathelement path="${classpath}"/><!-- is empty at this point? -->
      <pathelement location="saxon.jar"/><!-- saxon 6.4.4 -->
    </path>
    <path id="classpath.saxon.ext">
      <pathelement location="saxon644.jar"/><!-- db-xsl-1.45 -->
      <pathelement location="saxon64.jar"/><!-- db-website-2.0b1 -->
    </path>
    <path id="classpath.resolver">
      <pathelement location="resolver.jar"/>
      <pathelement location="."/><!-- for CatalogManager.properties -->
    </path>
    <path id="classpath.crimson">
      <pathelement location="crimson.jar"/>
    </path>
    <property name="html.generator" value="com.icl.saxon.StyleSheet"/>
    <property name="generator.args" value="-x
com.sun.resolver.tools.ResolvingXMLReader -y
com.sun.resolver.tools.ResolvingXMLReader -r
com.sun.resolver.tools.CatalogResolver"/><!-- "-t" -->
    ...
  <!-- =================================================================== -->
  <!-- Generate layout for stylesheets only if necessary                   -->
  <!-- =================================================================== -->
  <target name="autolayout.xml" depends="init-src">
    <style basedir="${build.src}"
           extension="xml"
           style="${build.src}/${autolayout.xsl}"
           destdir="${build.dest}"
           processor="trax"
           in="${build.src}/${layout.xml}"
           out="${build.src}/${autolayout.xml}">
      <classpath refid="classpath.saxon"/>
      <classpath refid="classpath.saxon.ext"/>
    </style>
  </target>

  <!-- =================================================================== -->
  <!-- Compiles the source directory                                       -->
  <!-- =================================================================== -->
  <target name="pre-compile" depends="init-src,autolayout.xml,template"
          description="Generate webpages by transforming sources through an XSLT processor.">
    <!-- Somehow basedir gets ignored, so source-docs are not found! -->
<!-- THE FOLLOWING STYLE-TASK DOES NOT WORK !
    <style basedir="${build.src}"
           style="${build.src}/${stylesheet}"
           destdir="${build.dest}"
           processor="trax"
           out="${build.src}/foo"
           in="${build.src}/${autolayout.xml}">
      <classpath refid="classpath.saxon"/>
      <classpath refid="classpath.saxon.ext"/>
      <classpath refid="classpath.resolver"/>
      <classpath refid="classpath.crimson"/>
    </style>
-->
<!-- just in case style should not work, use following: -->
<!-- dir is ignored if fork is not enabled ! -->
<!-- classpath.crimson is really needed to find crimson, at least if fork=yes
-->
    <java fork="yes" classname="${html.generator}" dir="${build.src}">
      <classpath refid="classpath.saxon"/>
      <classpath refid="classpath.saxon.ext"/>
      <classpath refid="classpath.resolver"/>
      <classpath refid="classpath.crimson"/>
      <sysproperty key="javax.xml.parsers.SAXParserFactory"
value="org.apache.crimson.jaxp.SAXParserFactoryImpl"/>
      <sysproperty key="javax.xml.transform.TransformerFactory"
value="com.icl.saxon.TransformerFactoryImpl"/>
      <arg line="${generator.args} ../../${build.src}/${autolayout.xml} 
../../${build.src}/${stylesheet}"/>
    </java>
    <copy todir="${build.dest}">
      <fileset dir="${build.predest}" includes="**/*"/>
    </copy>
  </target>
  ...
</project>

***<db:filename>CatalogManager.properties</db:filename>***:
#CatalogManager.properties

# 0 is off, 1 seemed to be also off so far
# 2 is reasonable, 4 is very verbosy (including catalog parse success!)
verbosity=1

# Always use semicolons in this list
catalogs=file:/d:/usr/share/sgml/CATALOG;file:/d:/usr/share/sgml/catalog.xml

prefer=public

static-catalog=yes

allow-oasis-xml-catalog-pi=yes

# catalog-class-name=com.sun.resolver.Resolver
#***EOF***


HTH,
Steffen.

-- 
  http://w3studi.informatik.uni-stuttgart.de/~maiersn/
mailto:Steffen.Maier@studserv.uni-stuttgart.de