Hi, Army, that's what I thought. When I read your documentation patch,
it said in numerous places:
"Derby currently requires a JAXP parser (such as Apache Xerces) and
Apache Xalan to be the in the Java classpath in order for the XML
operators to work. If either JAXP or Xalan is missing from the
classpath, Derby will disallow any XML-related operations."
Perhaps it is clear to *you* that this implies if your Java runtime
environment has XML then you are good to go, but that was not clear to
*me* :). It would be great to add something like this:
"Most Java virtual machines that are 1.4 or later have an XML parser
embedded, in which case you do not need to add anything to your
clsspath. If the JVM doesn't have its own parser, then you can put one
in your classpath and Derby will use that."
Thanks,
David
Army wrote:
David Van Couvering wrote:
Hi, Army. I thought you said in your code comments that you were just
going to use the XML parser that is part of the VM. Is that no longer
the case? Or did I misunderstand.
Derby will use whatever JAXP parser it finds in its classpath. If the
VM has an XML parser embedded (which most (all?) jvms that are 1.4 or
later do) then the XML parser from the VM will be used. If the jvm
doesn't have its own JAXP parser, then the user can put one in his/her
classpath and it'll use that. Thus the user can, for example, use XML
with 1.3 JVMs so long as s/he has some JAXP implementation and the Xalan
classes in his/her classpath.
If the VM has a parser embedded but it is overridden by Java's "endorsed
standards" technique, then the version that is endorsed will be picked
up by Derby, as expected.
So Yes, the Derby code will use the XML parser that is part of the VM,
if the VM has one.
Is there something in the documentation that is making you think otherwise?
Army
