You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Bernt M. Johnsen" <Be...@Sun.COM> on 2005/05/07 16:00:48 UTC
derbytools/dblook_test fails
I get,
*** Start: dblook_test jdk1.4.2_02 derbyall:derbytools 2005-05-06 22:37:37 ***
4861d4860
< java.io.FileNotFoundException: <filePath>
Test Failed.
*** End: dblook_test jdk1.4.2_02 derbyall:derbytools 2005-05-06 22:37:53 ***
which does not seem to have any connection to what I have
changed. Anyone who can comment on it? I assume the derbyall suite is
expected to pass without failures, is that correct?
Thanks,
Bernt
--
Bernt Marius Johnsen, Database Technology Group, Sun Microsystems, Norway
Re: derbytools/dblook_test fails
Posted by Dy...@Sun.COM.
Myrna van Lunteren <m....@gmail.com> writes:
> These is all valuable input...I've worked with this test harness for 3
> years or so, and as far as I know this has never come up...:-)
That's the beauty of open source I guess :)
> But I've been a bit in a quandary about what to do.
> Should we try to modify the test harness to allow any kind of
> directory structure?
> That's probably more work than I'm personally interested in investing
> in it...But if someone is interested enough to do it...
> Should we put a warning out for any 'unusual' characters? In the
> directory? Like spaces, colons...? That too might take some work but
> is probably doable.
> Or would just a mention in the README suffice?
I don't think it matters that much, but it should be mentioned
somewhere.
Btw. I don't think the problem with colons in the path is limited
to the test harness, since the error occurs inside the jdbc
driver... but I haven't verified it.
--
dt
Re: derbytools/dblook_test fails
Posted by Myrna van Lunteren <m....@gmail.com>.
These is all valuable input...I've worked with this test harness for 3
years or so, and as far as I know this has never come up...:-)
But I've been a bit in a quandary about what to do.
Should we try to modify the test harness to allow any kind of
directory structure?
That's probably more work than I'm personally interested in investing
in it...But if someone is interested enough to do it...
Should we put a warning out for any 'unusual' characters? In the
directory? Like spaces, colons...? That too might take some work but
is probably doable.
Or would just a mention in the README suffice?
Myrna
On 5/12/05, Dyre.Tjeldvoll@sun.com <Dy...@sun.com> wrote:
> Dyre.Tjeldvoll@Sun.COM writes:
>
> > "Dag H. Wanvik" <Da...@Sun.COM> writes:
> >
> > [snip]
> >
> >> so if your tests are running in a directory containing this pattern, a
> >> line too much is deleted from dblook_test.tmp, thereby giving a
> >> comparison failure like you describe.
> >>
> >> I don't know the reason for this deletion yet, so I can't say how to
> >> fix it, but the work-around is obvious: Run test in a directory whose
> >> name does not contain this pattern ;-)
> >
> > [snip]
> >
> > I have found a similar problem (in the test lang/closed.java, but I
> > think it applies to other tests as well). It turns out that the path
> > to the database created by a test (typically "wombat") cannot contain
> > ':'.
>
> [snip]
>
> While looking into DERBY-249 I discovered that the path to the test
> directory cannot contain spaces either. This is not obvious though,
> because "derbyall" seems to pass without problems, but when looking at
> derbyall_report.txt it appears that the entire test run only took 3
> minutes, and that only 163 tests were run...:
>
> OS name: Linux
> OS architecture: i386
> OS version: 2.4.20-31.9
> Java user name: dt136804
> Java user home: /home/dt136804
> Java user dir: /export/home/tmp/drby dev/derbyall_Linux_20050512T125758
> java.specification.name: Java Platform API Specification
> java.specification.version: 1.4
> --------- Derby Information --------
> JRE - JDBC: J2SE 1.4.2 - JDBC 3.0
> [/home/dt136804/derbyjars/derby.jar] 10.1.0.0 alpha - (169789M)
> [/home/dt136804/derbyjars/derbytools.jar] 10.1.0.0 alpha - (169789M)
> [/home/dt136804/derbyjars/derbynet.jar] 10.1.0.0 alpha - (169789M)
> [/home/dt136804/derbyjars/derbyclient.jar] 10.1.0.0 alpha - (169789M)
> [/usr/local/share/java/db2jcc/lib/db2jcc.jar] 2.4 - (17)
> [/usr/local/share/java/db2jcc/lib/db2jcc_license_c.jar] 2.4 - (17)
> ------------------------------------------------------
> ----------------- Locale Information -----------------
> Current Locale : [English/United States [en_US]]
> Found support for locale: [de_DE]
> version: 10.1.0.0 alpha - (169789M)
> Found support for locale: [es]
> version: 10.1.0.0 alpha - (169789M)
> Found support for locale: [fr]
> version: 10.1.0.0 alpha - (169789M)
> Found support for locale: [it]
> version: 10.1.0.0 alpha - (169789M)
> Found support for locale: [ja_JP]
> version: 10.1.0.0 alpha - (169789M)
> Found support for locale: [ko_KR]
> version: 10.1.0.0 alpha - (169789M)
> Found support for locale: [pt_BR]
> version: 10.1.0.0 alpha - (169789M)
> Found support for locale: [zh_CN]
> version: 10.1.0.0 alpha - (169789M)
> Found support for locale: [zh_TW]
> version: 10.1.0.0 alpha - (169789M)
> ------------------------------------------------------
> Test environment information:
> COMMAND LINE STYLE: jdk13
> TEST CANONS: master
> ------------------------------------------------------
> ------------------------------------------------------
> Summary results:
>
> Test Run Started: 2005-05-12 12:57:59.0
> Test Run Duration: 00:03:21
>
> 126 Tests Run
> 100% Pass (126 tests passed)
> 0% Fail (0 tests failed)
> 1 Suites skipped
> ------------------------------------------------------
>
> --
> dt
>
> However, experience shows that for many people and many applications a
> dose of paranoia is reasonable - Bjarne Stroustrup
>
>
Re: derbytools/dblook_test fails
Posted by Dy...@Sun.COM.
Dyre.Tjeldvoll@Sun.COM writes:
> "Dag H. Wanvik" <Da...@Sun.COM> writes:
>
> [snip]
>
>> so if your tests are running in a directory containing this pattern, a
>> line too much is deleted from dblook_test.tmp, thereby giving a
>> comparison failure like you describe.
>>
>> I don't know the reason for this deletion yet, so I can't say how to
>> fix it, but the work-around is obvious: Run test in a directory whose
>> name does not contain this pattern ;-)
>
> [snip]
>
> I have found a similar problem (in the test lang/closed.java, but I
> think it applies to other tests as well). It turns out that the path
> to the database created by a test (typically "wombat") cannot contain
> ':'.
[snip]
While looking into DERBY-249 I discovered that the path to the test
directory cannot contain spaces either. This is not obvious though,
because "derbyall" seems to pass without problems, but when looking at
derbyall_report.txt it appears that the entire test run only took 3
minutes, and that only 163 tests were run...:
OS name: Linux
OS architecture: i386
OS version: 2.4.20-31.9
Java user name: dt136804
Java user home: /home/dt136804
Java user dir: /export/home/tmp/drby dev/derbyall_Linux_20050512T125758
java.specification.name: Java Platform API Specification
java.specification.version: 1.4
--------- Derby Information --------
JRE - JDBC: J2SE 1.4.2 - JDBC 3.0
[/home/dt136804/derbyjars/derby.jar] 10.1.0.0 alpha - (169789M)
[/home/dt136804/derbyjars/derbytools.jar] 10.1.0.0 alpha - (169789M)
[/home/dt136804/derbyjars/derbynet.jar] 10.1.0.0 alpha - (169789M)
[/home/dt136804/derbyjars/derbyclient.jar] 10.1.0.0 alpha - (169789M)
[/usr/local/share/java/db2jcc/lib/db2jcc.jar] 2.4 - (17)
[/usr/local/share/java/db2jcc/lib/db2jcc_license_c.jar] 2.4 - (17)
------------------------------------------------------
----------------- Locale Information -----------------
Current Locale : [English/United States [en_US]]
Found support for locale: [de_DE]
version: 10.1.0.0 alpha - (169789M)
Found support for locale: [es]
version: 10.1.0.0 alpha - (169789M)
Found support for locale: [fr]
version: 10.1.0.0 alpha - (169789M)
Found support for locale: [it]
version: 10.1.0.0 alpha - (169789M)
Found support for locale: [ja_JP]
version: 10.1.0.0 alpha - (169789M)
Found support for locale: [ko_KR]
version: 10.1.0.0 alpha - (169789M)
Found support for locale: [pt_BR]
version: 10.1.0.0 alpha - (169789M)
Found support for locale: [zh_CN]
version: 10.1.0.0 alpha - (169789M)
Found support for locale: [zh_TW]
version: 10.1.0.0 alpha - (169789M)
------------------------------------------------------
Test environment information:
COMMAND LINE STYLE: jdk13
TEST CANONS: master
------------------------------------------------------
------------------------------------------------------
Summary results:
Test Run Started: 2005-05-12 12:57:59.0
Test Run Duration: 00:03:21
126 Tests Run
100% Pass (126 tests passed)
0% Fail (0 tests failed)
1 Suites skipped
------------------------------------------------------
--
dt
However, experience shows that for many people and many applications a
dose of paranoia is reasonable - Bjarne Stroustrup
Re: derbytools/dblook_test fails
Posted by Dy...@Sun.COM.
"Dag H. Wanvik" <Da...@Sun.COM> writes:
[snip]
> so if your tests are running in a directory containing this pattern, a
> line too much is deleted from dblook_test.tmp, thereby giving a
> comparison failure like you describe.
>
> I don't know the reason for this deletion yet, so I can't say how to
> fix it, but the work-around is obvious: Run test in a directory whose
> name does not contain this pattern ;-)
[snip]
I have found a similar problem (in the test lang/closed.java, but I
think it applies to other tests as well). It turns out that the path
to the database created by a test (typically "wombat") cannot contain
':'.
public String PersistentServiceImpl::getCanonicalServiceName(String name)
looks for the first occurence of ':' in name, and assumes that what
follows is equal to the protocol:
public String getCanonicalServiceName(String name)
{
String protocolLeadIn = getType() + ":";
int colon = name.indexOf( ':');
if( colon > 1) // Subsubprotocols must be at least 2 characters long
{
if( ! name.startsWith( protocolLeadIn))
return null; // It is not our database
name = name.substring( colon + 1);
For those who wonder why I insist on having ':' in the path, the answer
is that I don't. I did, however, use the UNIX command 'date' to get a unique
directory name for each test run.
I have now changed the argument to date, so that I get a time stamp
without ':', and that seems to work.
--
dt
Re: derbytools/dblook_test fails
Posted by "Dag H. Wanvik" <Da...@Sun.COM>.
Hi,
BMJ> > > *** Start: dblook_test jdk1.4.2_02 derbyall:derbytools 2005-05-06 22:37:37 ***
BMJ> > > 4861d4860
BMJ> > > < java.io.FileNotFoundException: <filePath>
BMJ> > > Test Failed.
BMJ> > > *** End: dblook_test jdk1.4.2_02 derbyall:derbytools 2005-05-06 22:37:53 ***
I had this same problem and debugged it. The problem lies with the sed
functionality in the test harness, which delete certain lines before
comparing with the master file.
Sed.java in harness removes lines containing *derby/* in the path,
viz:
deleteLines.addElement("^.*derby/.*\\<.*\\>\\(.*\\).*$");
deleteLines.addElement("^.*derby/.*\\(.*\\).*$");
so if your tests are running in a directory containing this pattern, a
line too much is deleted from dblook_test.tmp, thereby giving a
comparison failure like you describe.
I don't know the reason for this deletion yet, so I can't say how to
fix it, but the work-around is obvious: Run test in a directory whose
name does not contain this pattern ;-)
I will file a JIRA issue for this.
Dag
>>>>> "BMJ" == Bernt M Johnsen <Be...@Sun.COM> skriver:
BMJ>
BMJ> Hi Myrna & thanks for your answer.
BMJ> >>>>>>>>>>>> Myrna van Lunteren wrote (2005-05-08 17:12:58):
BMJ> > Hi Bernt,
BMJ> >
BMJ> > Yes, derbyall suite should pass...
BMJ> >
BMJ> > Whenever there's a test failure in the full suite, step 1 is to run
BMJ> > the test by itself.
BMJ> > Does that fail too?
BMJ>
BMJ> Yes. I've done that.
BMJ>
BMJ> >
BMJ> > I synced up (revision 126411) & built & the test ran fine...by
BMJ> > itself...(RunTest).
BMJ> >
BMJ> > It's a little hard to advise you, I'd need some more info; e.g. is
BMJ> > derbytools.jar in your classpath? or are you using the 'classes'
BMJ> > directory?
BMJ>
BMJ> derbytools.jar is in my classpth and I don't use the classes directory.
BMJ>
BMJ> > If you are using the jars & you built them yourself, maybe indeed a
BMJ> > class or file is missing? assuming you built by using the 'all' and
BMJ> > then the 'buildjars' target...
BMJ> > I'm really curious as to which file is not getting found.
BMJ>
BMJ> Well, actually it is the other way round: The master is like this
BMJ> (last 8 lines):
BMJ>
BMJ> Msg Test 5
BMJ> ************
BMJ> File dblook.log was NOT empty. Contents are:
BMJ> ############## Begin File Contents ################
BMJ> -- **--> DEBUG: Failed to load jar file <jarFilePath>
BMJ> java.io.FileNotFoundException: <filePath>
BMJ> ############## End File Contents ################
BMJ> [ Done. ]
BMJ>
BMJ> while my result is:
BMJ>
BMJ> Msg Test 5
BMJ> ************
BMJ> File dblook.log was NOT empty. Contents are:
BMJ> ############## Begin File Contents ################
BMJ> -- **--> DEBUG: Failed to load jar file <jarFilePath>
BMJ> ############## End File Contents ################
BMJ> [ Done. ]
BMJ>
BMJ>
BMJ> >
BMJ> > Myrna
BMJ> >
BMJ> >
BMJ> > On 5/7/05, Bernt M. Johnsen <Be...@sun.com> wrote:
BMJ> > > I get,
BMJ> > >
BMJ> > > *** Start: dblook_test jdk1.4.2_02 derbyall:derbytools 2005-05-06 22:37:37 ***
BMJ> > > 4861d4860
BMJ> > > < java.io.FileNotFoundException: <filePath>
BMJ> > > Test Failed.
BMJ> > > *** End: dblook_test jdk1.4.2_02 derbyall:derbytools 2005-05-06 22:37:53 ***
BMJ> > >
BMJ> > > which does not seem to have any connection to what I have
BMJ> > > changed. Anyone who can comment on it? I assume the derbyall suite is
BMJ> > > expected to pass without failures, is that correct?
BMJ> > >
BMJ> > > Thanks,
BMJ> > > Bernt
BMJ> > > --
BMJ> > > Bernt Marius Johnsen, Database Technology Group, Sun Microsystems, Norway
BMJ> > >
BMJ>
BMJ> --
BMJ> Bernt Marius Johnsen, Database Technology Group,
BMJ> Sun Microsystems, Trondheim, Norway
BMJ>
--
Dag H. Wanvik
Sun Microsystems, Web Services, Database Technology Group
Haakon VII gt. 7b, N-7485 Trondheim, Norway
Tel: x43496/+47 73842196, Fax: +47 73842101
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact
the sender by reply email and destroy all copies of the original
message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: derbytools/dblook_test fails
Posted by "Bernt M. Johnsen" <Be...@Sun.COM>.
Hi Myrna & thanks for your answer.
>>>>>>>>>>>> Myrna van Lunteren wrote (2005-05-08 17:12:58):
> Hi Bernt,
>
> Yes, derbyall suite should pass...
>
> Whenever there's a test failure in the full suite, step 1 is to run
> the test by itself.
> Does that fail too?
Yes. I've done that.
>
> I synced up (revision 126411) & built & the test ran fine...by
> itself...(RunTest).
>
> It's a little hard to advise you, I'd need some more info; e.g. is
> derbytools.jar in your classpath? or are you using the 'classes'
> directory?
derbytools.jar is in my classpth and I don't use the classes directory.
> If you are using the jars & you built them yourself, maybe indeed a
> class or file is missing? assuming you built by using the 'all' and
> then the 'buildjars' target...
> I'm really curious as to which file is not getting found.
Well, actually it is the other way round: The master is like this
(last 8 lines):
Msg Test 5
************
File dblook.log was NOT empty. Contents are:
############## Begin File Contents ################
-- **--> DEBUG: Failed to load jar file <jarFilePath>
java.io.FileNotFoundException: <filePath>
############## End File Contents ################
[ Done. ]
while my result is:
Msg Test 5
************
File dblook.log was NOT empty. Contents are:
############## Begin File Contents ################
-- **--> DEBUG: Failed to load jar file <jarFilePath>
############## End File Contents ################
[ Done. ]
>
> Myrna
>
>
> On 5/7/05, Bernt M. Johnsen <Be...@sun.com> wrote:
> > I get,
> >
> > *** Start: dblook_test jdk1.4.2_02 derbyall:derbytools 2005-05-06 22:37:37 ***
> > 4861d4860
> > < java.io.FileNotFoundException: <filePath>
> > Test Failed.
> > *** End: dblook_test jdk1.4.2_02 derbyall:derbytools 2005-05-06 22:37:53 ***
> >
> > which does not seem to have any connection to what I have
> > changed. Anyone who can comment on it? I assume the derbyall suite is
> > expected to pass without failures, is that correct?
> >
> > Thanks,
> > Bernt
> > --
> > Bernt Marius Johnsen, Database Technology Group, Sun Microsystems, Norway
> >
--
Bernt Marius Johnsen, Database Technology Group,
Sun Microsystems, Trondheim, Norway
Re: derbytools/dblook_test fails
Posted by Myrna van Lunteren <m....@gmail.com>.
Hi Bernt,
Yes, derbyall suite should pass...
Whenever there's a test failure in the full suite, step 1 is to run
the test by itself.
Does that fail too?
I synced up (revision 126411) & built & the test ran fine...by
itself...(RunTest).
It's a little hard to advise you, I'd need some more info; e.g. is
derbytools.jar in your classpath? or are you using the 'classes'
directory?
If you are using the jars & you built them yourself, maybe indeed a
class or file is missing? assuming you built by using the 'all' and
then the 'buildjars' target...
I'm really curious as to which file is not getting found.
Myrna
On 5/7/05, Bernt M. Johnsen <Be...@sun.com> wrote:
> I get,
>
> *** Start: dblook_test jdk1.4.2_02 derbyall:derbytools 2005-05-06 22:37:37 ***
> 4861d4860
> < java.io.FileNotFoundException: <filePath>
> Test Failed.
> *** End: dblook_test jdk1.4.2_02 derbyall:derbytools 2005-05-06 22:37:53 ***
>
> which does not seem to have any connection to what I have
> changed. Anyone who can comment on it? I assume the derbyall suite is
> expected to pass without failures, is that correct?
>
> Thanks,
> Bernt
> --
> Bernt Marius Johnsen, Database Technology Group, Sun Microsystems, Norway
>