db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1496) testSecMec fails with jcc2.8 with 131 jvms
Date Fri, 28 Jul 2006 00:23:14 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1496?page=comments#action_12423966 ] 
Daniel John Debrunner commented on DERBY-1496:

Just looking at datasourcepermissions I would say you are generally on the right track, but
when I run the test using JUnit directly it fails for me.  I think starting by running it
in JUnit alone is the best approach, forget the test harness and focus on JUnit.

Your suite method (correctly) creates four test cases, or as JUnit says "fixtures". Each fixture
will run the setUp and tearDown methods of the class, thus you will run them four times. I
don't know if  that's what you meant or not. If you want it to be once per-suite then you
create a decorator.

Think about the normal mode for Junit tests to be that Derby is already running with a database
created and the tests are just run against that database. We need to have some decorators
that ensure the database is clean, but you can work without them for now (just remove the
database each time you run, that's what the test harness will do when you finally plug into
that). I say this because you code is shutting down Derby and re-booting it, I'm not sure
why, it may be inherited from the old test and it may be required, but it would be good to
keep the normal mode in mind.

Also look at the BaseJDBCTest class and the TestConfiguraiton class, if we can factor out
DriverManager calls then we also run these tests on J2ME.

One way to stage this would be to create a new JUnit test class based upon datasourcepermissions
.java rather than having to convert both tests at the same time, then once your new class
is working move onto the _net approach.

One more thing that jumps oput at me is the setting of the database properties, that's code
that could be common. I just created a SystemPropertyTestSetup class that sets system properties
based upon a passed in set, setting database properties could be handled the same way, rather
than have each test do it itself.

> 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