�ystein Gr�vlen wrote: > Thank you very much for your helpful advice. I am still learning > about the testing framework, and I have a few questions below. > > >>>>>>"A" == Army <[EMAIL PROTECTED]> writes: > > > A> My one comment is that you don't run the new > A> ConcurrentImplicitCreateSchema.java test against the Network > A> Server--is there a reason for that? > > I must admit that I did not understand what was needed to get it to > run as part of the network server test. I am still a bit confused, > because earlier today one email contained something about putting a > test in some file to _exclude_ it from the network server test. > > A> This diff occurs because no user/id is provided on the > A> "getConnection()" call that occurs in the constructor for CreateTable. > A> I added a dummy user and password value to that call and re-ran the > A> test against Network Server, and it passed (both with the JCC client > A> and with Derby Network Client). SO, I think it'd be good to make this > A> change as part of the patch and then to add > A> "lang/ConcurrentImplicitCreateSchema.java" to the > A> "derbynetmats.runall" file so that it runs against the server, as > A> well. > > I will do this and resubmit the patch. Should it also be added to the > derbynetclientmats.runall?
Any reason why this test doesn't use the same mechanism as the other java tests to get a connection? Direct use of DriverManager automatically excludes the test from being run in JSR169. The util.startJBMS() call you see in other tests should be the preferred way to get a connection. This will then pick up any test properties that modify how connections should be obtained. Dan.
