[ http://issues.apache.org/jira/browse/DERBY-2153?page=comments#action_12456171 ] A B commented on DERBY-2153: ----------------------------
> I think that could be simplified with: > DocumentBuilderFactory.newInstance().getClass() Yes, you're absolutely right. I'll include this in my patch for this issue. > and then reading the comments above this line, I wonder if this could have > been > used instead? > DocumentBuilderFactory.class I don't think this will always work. The 1.4, 1.5, and 1.6 JVMs (at least, Sun and IBM) all embed the JAXP API classes. But in the case of, say, Sun 1.5, the JAXP *implementation* classes are not embedded. So if we're running with Sun 1.5 then any attempts to look up the URL for "DocumentBuilderFactory.class" would return null because it's embedded within the JVM. But if we have an external JAXP implementation (say Xerces) in the classpath, we need to find that jar file. By instantiating the DocBuilderFactory class and using the the *implementation*-specific class name we ensure that, for external (w.r.t the JVM) JAXP implementations, we can find the implementation jar file and thus we can assign the correct permissions. Note that I haven't tried it yet, but if the user was using Sun 1.5 and *endorsed* the JAXP parser, I think the use of DocumentBuilderFactory.class would work. But I don't think we want to make that a requirement, do we? > Also the coment you quoted above says "The following import is for a JDBC 3.0 > JAXP class". > I think you meant to say something instead of JDBC 3.0, since JAXP is not > part of JDBC. Okay, I think I've made this mistake before (sorry). Will change it in my patch. > suites.All falls over with foundation after revision 482433; > java.lang.NoClassFoundError: javax.xml.parsers.DocumentBuilderFactory > ---------------------------------------------------------------------------------------------------------------------------------- > > Key: DERBY-2153 > URL: http://issues.apache.org/jira/browse/DERBY-2153 > Project: Derby > Issue Type: Bug > Components: Test > Affects Versions: 10.3.0.0 > Environment: IBM's wctme5.7 (a.k.a. j9) jcl Foundation libraries > (j2MEjdk 1.0) > Reporter: Myrna van Lunteren > Assigned To: A B > > When attempting to run: > <j9binpath>/j9 -jcl:foun10 -Dderby.system.home=<testhome> > -DderbyTesting.serverhost=localhost -DderbyTesting.clienthost=localhost > -DderbyTesting.codeclasses=file:/<classesdir>/ > -DderbyTesting.junit=file://unused -DderbyTesting.antjunit=file://unused > -Djava.security.policy=file:/<classesdir>/org/apache/derbyTesting/functionTests/util/derby_tests.policy > -Xbootclasspath/a:<j9libpath>/jdbc.jar -cp <classesdir>;junit.jar > junit.textui.TestRunner org.apache.derbyTesting.functionTests.suites.All > The textui.TestRunner keels over with the following error: > Failed to invoke suite():java.lang.NoClassDefFoundError: > javax.xml.parsers.DocumentBuilderFactory > This happens after, but not before revision 482433. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
