db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Myrna van Lunteren (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-1496) testSecMec fails with jcc2.8 with 131 jvms
Date Sun, 23 Jul 2006 03:00:14 GMT
     [ http://issues.apache.org/jira/browse/DERBY-1496?page=all ]

Myrna van Lunteren updated DERBY-1496:

    Attachment: DERBY-1496_tmp_072206.stat

This is my first real foray into the realm of junit tests...
And I got mixed results, so far.

I would really appreciate it if someone interested in converting tests to junit, or someone
who knows how junit tests are supposed to look could review what I've done so far and give
me feedback...

The attached patch - DERBY-1496_tmp_072206.* - doesn't modify testSecMec.java at all...
Because testSecMec.java extends dataSourcePermissions_net.java which extends dataSourcePermissions.java
and I'm currently stuck on converting the dataSourcePermissions_net test.

This is what I did:
I started converting jdbcapi/dataSourcePermissions.java which seemed to go well enough.

My first step was to just run the test as a junit test, which meant:
- remove main method
- add setUp method
- add constructor for taking test name
- extend from BaseJDBCTestCase
- replace cleanUp with tearDown
- add test methods that start with 'test' for the actual string
- replace chatty System.out.printlns with println 
Then I ran this test with 
   java -Dverbose=true -Dkeepfiles=true -Djvmflags=-Dderby.test.debug=true org.apache.derbyTesting.functionTests.harness.RunTest
The resulting .out was hard to deal with using my vdiff32 on windows, so I
went ahead and added DEBUG and .DEBUG to Sed.java to be filtered during my conversion
Now the resulting diff was easy to oversee.
The next step was to convert all the checkConnections to assertTrue.
Reran the test, then reran withouth the derby.test.debug and got rid of the .out.

As an afterthought, I created a testSuite method.

So far so good, much encouraged, I went on to work on dataSourcePermissions_net.java.
And that's as far as I got.

Problem 1:
One of the aspects is that I had to add grant a number of permissions that are granted to
various jars already, but apparently had to be added again - maybe to junit?

Problem 2:
There seemed to be no efficient way to get a simple connection to networkserver using a different
port than the default 1527. I was quite surprised really that the original test was able to
do this with ij.startJBMS().
I contacted Kathey on the IRC and she said the 20000 was put in at a time that there was no
startServer=false property, so it could go back to 1527 now. 
So that's what the test is doing currently, but I would like to make a way to get connections
to a different port.

Problem 3:
The current test executes setUp and tearDown a number of times. Each time it also calls the
super methods. I think I did this wrong, but I am not clear on how to do it instead.
Probably some of the setup needs to go into a decorator. I'll experiment with that next.

Problem 4:
For some reason, I currently only get output for the testDriverManagerPermissions subtest.
It's very strange, in the (eclipse) debugger I can see that junit apparently does recognize
that it needs to do something with these tests, but all it ends up doing are setUps and tearDowns
and shutdowns and starts. No doubt because of me call supers, but I still don't see why it's
not running the tests.

So, I'll keep muddling on, but I thought I'd log what I've done so far. 

Obviously, this patch is not suitable for commit.

> testSecMec fails with jcc2.8 with 131 jvms
> ------------------------------------------
>                 Key: DERBY-1496
>                 URL: http://issues.apache.org/jira/browse/DERBY-1496
>             Project: Derby
>          Issue Type: Improvement
>          Components: Test
>    Affects Versions:
>            Reporter: Sunitha Kambhampati
>         Assigned To: Myrna van Lunteren
>            Priority: Minor
>         Attachments: DERBY-1496_tmp_072206.diff, DERBY-1496_tmp_072206.stat
> derbynet/testSecMec.java fails with jcc2.8 with 131 vms.   I have checked the diff and
it is a master update with difference in the exception, message string.
> diff snippet:
> 8 del
> < T5: jdbc:derby:net://xxxFILTERED_HOSTNAMExxx:xxxFILTEREDPORTxxx/wombat:user=neelima;password=lee;securityMechanism=9;
- EXCEPTION java.security.InvalidAlgorithmParameterException is caught when initializing EncryptionManager
'Prime size must be multiple of 64, and can only range from 512 to 1024 (inclusive)'
> 8a8
> > T5: jdbc:derby:net://xxxFILTERED_HOSTNAMExxx:xxxFILTEREDPORTxxx/wombat:user=neelima;password=lee;securityMechanism=9;
- EXCEPTION java.security.NoSuchAlgorithmException is caught when initializing EncryptionManager
'DH KeyPairGenerator not available'
> 14 del
> ----------------
> There is difference in the exception message and will require lot of jvm specific master
files which can become difficult to maintain.  Myrna suggested that  this might be a good
test to convert to junit. 

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