cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Boag/CAM/Lotus" <>
Subject Re: "org.xml.sax.driver" System Property and duplicate files.
Date Mon, 09 Oct 2000 23:04:00 GMT

OK, here's what I did (the changes will be checked in later tonight):

1) Processor#newInstance is looking for a property of "trax.processor."
+type (this hasn't changed).  For a XSLT transformer, trax.processor.xslt.

2) If it finds a system property of that name, it uses that.  This allows
overriding the property via -Dtrax.processor.xslt=""
on the command line.

3) If it doesn't find the property, it tries to load the properties by
default from "", via getResourceAsStream.  The client
application can overload what property file is used via

4) If a good class is still not found, it will use
Processor#platformDefaultFactoryName, which can be overridden via

5) For the serializer, it is pretty much the same, although it will not try
to use the System properties, as it's needs are more complicated.

6) Right now Xalan loads a system property default for org.xml.sax.driver
from  I want to change this, as I
realize that there is a XMLReaderFactory#createXMLReader (String
className), so I will probably load the default className via

7) DocumentBuilderFactory#newInstance simply uses the system property
javax.xml.parsers.DocumentBuilderFactory.  It currently uses
org.apache.xerces.jaxp.DocumentBuilderFactoryImpl, at least the version I
obtained from Xerces.

The should work better than before, but is still not perfect.  The whole
configuration structure is more complicated than I would like, but I'm not
sure what to do about that.  If anybody feels I am moving in the wrong
direction, please let me know.  I'm open to better ideas.

> Cent #2: There should be no duplicate files Xalan.jar should not contain
any files in Xerces.jar
or vice versa.

Ah.  Now this may be an interesting controversy.  I have recently included
the needed DOM2 interfaces, SAX interfaces, and JAXP interfaces.  Do you
disagree with this?  My reasoning is that I feel you should be able to
compile Xalan without pointing to a given parser, and also, you should be
able to write a simple transformation program without having to have the
parser on the classpath (indeed, you may be writing a transformation that
doesn't use a parser at all).  Also, I feel that, abstractly, it's not such
a bad thing for a program to carry the interfaces it needs.  I think it
will also help documentation and the like.  Anyhow, I'm not immoveable on
this, but I kind of like it.

Were there other files where you were worried about duplicates?


View raw message