Knut Anders Hatlen wrote:
OK, so if we did some kind of reflection trick in SqlXmlUtil to use the com.sun.org.apache.xalan package if org.apache.xalan wasn't there, that would probably work.
Hmm...would this me we were coding Derby for a specific JVM (or set of JVMs)? Is that a precedence we really want to set? Sure, it's Sun's JVM, but still...do we do have any other specific logic in the Derby code?
Hmm, there is also a com.sun.org.apache.xerces.internal.impl.xpath.XPath class that we could check for. Its existence would at least give us the same guarantee as org.apache.xpath.XPath, I think.
Same question as above.
If we require Xalan specific classes/methods and cannot only rely on generic interfaces, then I agree, Xalan is what we should check for.
I think this is probably the way to go.
I'll log a JIRA issue for this, since it seems like a great usability improvement not to require separate downloads when the JVM has what's needed.
I think it's important to make sure we're talking about the same Jira. I think it makes sense to file an issue for checking specifically for Xalan classes. I'm not so sure I like the idea of adding code to check for a set of classes that are only present in Sun jdks. That makes me a little uncomfortable...
Army
