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] Updated: (DERBY-1758) Enable xmlSuite to run as part of derbyall for JVMs that embed the required external jars.
Date Fri, 01 Dec 2006 19:11:22 GMT
     [ http://issues.apache.org/jira/browse/DERBY-1758?page=all ]

A B updated DERBY-1758:

    Attachment: d1758_secmgr_v1.patch

Attaching a patch, d1758_secmgr_v1.patch, that enables the lang/XMLBindingTest to run under
a security manager.  Changes include all of the following:

 - Updates lang/XMLBindingTest.java so that it will run under the default testing security
manager (i.e. removed the "noSecurityManager()" wrapper).

 - Adds a new property, derbyTesting.jaxpjar, to the default testing policy file.  This property
holds the location of the JAXP jar picked up from the classpath _if_ that jar is external
to the JVM. If the jar is either embedded within, or "endorsed" by, the JVM then this property
is unused.

    The JAXP jar is then given permission to read the "extin" testing directory, which is
the directory into which the DTD required by XMLBindingTest is copied (and thus JAXP has permission
to read the DTD file).

 - Adds a new static utility method, "getJAXPParserLocation()", to the junit/XML.java file.
 This method instantiates a JAXP object and then uses the implementation-specific class name
to try to find out where the JAXP jar is located.

- Modifies derbyTesing/junit/build.xml so that junit/XML.java will only build with 1.4 JVMs
and higher.  This is required because junit/XML.java now references a JAXP class that is not
defined in 1.3.

 - Updates the "getURL()" method of junit/SecurityManagerSetup.java to account for situations
where a class "code source" is null.  Also updates the "determineClasspath()" method of that
class to set the derbyTesting.jaxpjar property as appropriate.

 - And finally, moves the build order of the derbyTesting/junit directory so that it is built
*before* the derbyTesting/harness directory.  This is required because the harness/jvm.java
file references junit/SecurityManagerSetup.java, which in turn references junit/XML.java (with
this patch).  So when we try to compile the "harness" directory we will indirectly try to
compile junit/XML.java using the harness/build.xml file--but that specific build file does
not know that junit/XML.java is only supposed to be built with 1.4. By putting the junit target
first we ensure that the junit/XML.java file is built with the junit/build.xml file, which
knows not to use 1.3.  At least, that's my understanding of the build process works.  Someone
please correct me if I'm wrong (and I very well could be...).

I would appreciate reviews if anyone has the time (esp. anyone familiar with JUnit security
manager testing and/or the build.xml files...)

> Enable xmlSuite to run as part of derbyall for JVMs that embed the required external
> ------------------------------------------------------------------------------------------
>                 Key: DERBY-1758
>                 URL: http://issues.apache.org/jira/browse/DERBY-1758
>             Project: Derby
>          Issue Type: Task
>          Components: Test
>    Affects Versions:,,
>            Reporter: A B
>         Assigned To: A B
>         Attachments: d1758_followup_v1.patch, d1758_newJUnitTests_v1.patch, d1758_newJUnitTests_v1.stat,
d1758_newJUnitTests_v2.patch, d1758_newSecMgr_doNotCommit.patch, d1758_newXBindTest_v1.patch,
d1758_newXMLSuite_v1.patch, d1758_remove_xbindAndSuite.patch, d1758_remove_xgen_v1.patch,
d1758_remove_xgen_v1.stat, d1758_secmgr_v1.patch, d1758_secmgr_v1.stat
> Due to the fact the XML support in Derby has external dependencies on Apache Xalan and
a JAXP parser (such as, but not limited to, Apache Xerces), the tests for XML, which are all
included in "xmlSuite", are not currently run as part of derbyall.
> Changes for DERBY-688 (and DERBY-567 indirectly) have now made it so that JVMs which
have Apache Xalan and a JAXP parser embedded in them can run the XML tests without requiring
additional jars, assuming that the embedded version of Xalan is at least the minimum version
required by Derby (which is currently 2.5).
> So given that, the xmlSuite should be enabled as part of derbyall for any JVMs that are
capable of running them.  Currently, this appears to mean only ibm142 and ibm15.
> Per comments in DERBY-688, enabling the XML suite could include the following tasks:
>   1. Enable the suite to run as part of derbyall but ONLY for JVMs that
>      embed the required Xalan/JAXP classes.
>   2. Resolve the following diff in lang/xmlBinding.java that occurs on
>      some platforms (ex. Linux):
>     < Inserted roughly 40k of data.
>     10 del
>     < Inserted roughly 40k of data.
>     10a9,10
>     > Inserted roughly 39k of data.
>     > Inserted roughly 37k of data.
>     21 del
>     < 1, [ roughly 40k ]
>     22 del
>     < 2, [ roughly 40k ]
>     22a21,22
>     > 1, [ roughly 39k ]
>     > 2, [ roughly 37k ]
>   3. Add new tests to verify Derby behavior when XML classes are
>     not present.
> Note that #3 may turn out to be its own Jira issue; the first two, however, should both
be addressed as part of this issue since the xmlSuite will not run (and pass) on all platforms
if either 1 or 2 is not addressed.

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


View raw message