Army wrote:
Andreas Korneliussen wrote:
I noticed that /java/engine/org/apache/derby/iapi/types/XML.java uses
the org.apache.xalan.processor.TransformerFactoryImpl class,and it had
the following comments:
// Note that even though the following has a Xalan
// package name, it IS part of the JDK 1.4 API, and
// thus we can compile it without having Xalan in
// our classpath.
import org.apache.xalan.processor.TransformerFactoryImpl;
As part of my (currently stalled) work for DERBY-688 I have reorganized
the XML code in some key ways with the goal of allowing XML.java to
build without any dependency on Xalan. Those changes include the
movement of all Xalan-related dependencies into a separate class that is
only loaded at runtime _if_ Xalan is in the user's classpath.
I haven't had a chance to complete that work yet because I've been
focusing on other issues lately--but I do hope to have the changes
complete for 10.2. All of that said, let me now answer your two questions:
The JDK 1.5 API and runtime, does not have this class, (it has been
renamed), so I have the following questions:
1. Is it necessary to use the impl class, instead of accessing the
object through the TransformerFactory interface ?
The current Derby code uses the impl class because it (the impl class)
defines two methods that are not part of the TransformerFactory API:
namely, newTemplatesHandler() and newTransformerHandler(). The current
code uses those classes to process stylesheets to in turn evaluate XPath
expressions.
There may be a way to accomplish the same thing indirectly by using
other methods that are part of the standard API, but I don't know off
hand if that's the case. In any event, with my changes for DERBY-688
I've rewritten the XPath evaluation code to _not_ use stylesheets and to
instead use the lower-level Xalan XPath API. This means that
TransformerImpl is no longer required--but of course there are other
Xalan-specific classes that are necessary, so in the end the depenency
on Xalan is still there. But it's been moved out of XML.java into
another class.
Which leads to the next question:
2. At runtime, is there a guarantee that the class is available when
using Java 1.5 JDK and using XML functionality ? I noticed the class
is also inside xalan.jar, so I guess that this functionality requires
this jar file to be included at runtime.
When I originally submitted the XML type and initial operators
(DERBY-334) I did so with the expectation that the XML type would only
work if Xalan was in the user's classpath. That's why the XML tests do
not currently run as part of derbyall--I didn't want to force anyone
running the tests to have to download Xalan (or Xerces for that matter)
just to run the regression tests.
As for runtime checks, the current code doesn't explicitly check for
Xalan, so the result will be some sort of ClassNotFound or NoClassDef
exception. That might seem silly, but the whole tone of DERBY-334 was
that the XML datatype was a new type that was not ready for production
use--which is why I haven't documented it yet (and which is why we've
been able to get by so far without running nightly regression tests).
With DERBY-688, though, I will be adding better run-time checks to throw
more user-friendly errors if the required Xalan classes aren't found. I
will also reorganize the code, as mentioned above, to remove Xalan
dependencies from XML.java, which is the base type for XML columns, so
that users can operate on tables with XML columns even if they don't
have Xalan in their classpath, assuming they don't actually reference
the XML columns (currently that's not possible).
Additional changes targeted for DERBY-688 are described in that issue
and the corresponding spec (which, I admit, needs to be updated). The
intent is that, by making these changes, we can make XML an "official"
Derby datatype ready for production use, and thus we can add it to the
documentation. Most of the changes are well on their way to completion,
I just have to tie up some loose ends and make everything "official".
As I said, I'm hoping to do that for the 10.2 release...
Does that answer your questions?
Yes, thank you very much for you explanations
--Andreas
Army
