I had a jar-only test working, using the mechanism I mentioned to see if
the test class was loaded from a jar or not. This is with the
assumption that if the test class is loaded from a jar, then everything
is loaded from jars. Alternately one could load a Derby class and see
if it was loaded from a jar.
Rick, if you're interested, I'll send you the code.
David
Daniel John Debrunner wrote:
Rick Hillegas wrote:
Be interesting to see what cannot be run when using the classes
directly
I'm building the JDBC4 support for autoloading the driver. This involves
writing your driver name into a special location in the jar file. The
autoloading test needs to get a connection to Derby without ever
mentioning the Derby driver. This should only succeed if run against jar
files under jdk1.6.
Cool I'd hoped someone was going to add that.
You could have/simulate the same behaviour for classes and pre-jdk 1.6
by using the System property jdbc.drivers. Something that isn't
currently tested.
If you do go the jar only route, for purely selfish reasons a jar only
suite would be useful for me in the future. I've been thinking about
tests to ensure the packages are sealed, by having procedures or
functions load classes that extend derby classes. But I'm a long way off
getting round to attempting it.
Thanks,
Dan.
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
