db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A B (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2153) suites.All falls over with foundation after revision 482433; java.lang.NoClassFoundError: javax.xml.parsers.DocumentBuilderFactory
Date Wed, 06 Dec 2006 19:22:22 GMT
    [ 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

        

Mime
View raw message