History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: CASTOR-943
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Ralf Joachim
Reporter: Martin Fuchs
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
castor

Create a test case for bug 1785 (JDO DataSource configuration using a Properties collection)

Created: 29/Nov/04 12:51 PM   Updated: 28/Aug/05 05:03 PM
Component/s: JDO
Affects Version/s: 0.9.5.4
Fix Version/s: 0.9.9 M1

Time Tracking:
Original Estimate: 2 hours
Original Estimate - 2 hours
Remaining Estimate: 2 hours
Remaining Estimate - 2 hours
Time Spent: Not Specified
Remaining Estimate - 2 hours

File Attachments: 1. Text File castor-JdoConf-UnitTest.patch (7 kb)
2. Text File patch-C943-20050806.txt (15 kb)

Environment:
Operating System: All
Platform: All
Issue Links:
Related
 


 Description  « Hide
[Martin]
Well, this is a bit difficult. The JDO-CTF internally configures the database
connection, so I can't use it to test JdoConfFactory.
In bug 1785 there is attached a JUnit test case:
http://bugzilla.exolab.org/attachment.cgi?id=766&action=view
The test class is configured to use an Oracle Database, but can be changed
ithout problems to use other drivers. (see the string constants at the top)

[Werner]
Additional Comment #4 From Werner Guttmann 2004-11-12 00:53 -------
No problem, Martin, as you can add 'independent' JUnit test cases to src/tests,
i.e. test cases that are not part of the test suite. There's already some at
src/tests/org/exolab/castor/jdo.**.

Patch (code only) applied as provided. Martin, I decided not to include the test
case as it stands, for the reasons described above. And I didn't want to include
it as a simple JUnit test case either, as this would imply creating new config
files, which I don't think is ideal.

[Martin]
OK - is there anyone with a superb idea how to intergrate this test case in the
other tests without having to extend the test framework too much?



 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Werner Guttmann - 14/Dec/04 06:49 AM
Bruce ?

Werner Guttmann - 08/Mar/05 08:08 AM
Martin, I think by specifying a new category, this should do the trick. Once
you've done that, you'll be able to specify a separate JDO config file.

Werner Guttmann - 31/Mar/05 01:04 AM
Martin, just reading through this again, and it just occured to me that we ship
by definition the postgreSQL JDBC driver as part of the complete distribution
JAR. What woukld you thin of converting your test case to use a postgreSQL
instance with default port numnbers and database names ?

Ralf Joachim - 05/May/05 04:36 AM
Attached test case from bug 1785.

Ralf Joachim - 05/May/05 04:57 AM
I intend to commit attached test after some small changes into src/tests/jdo/test1785 directory without integration into CTF. The integartion of this test and also 3 others (test1214, test1781and test1865) into CTF need to take place later as we will need a bigger refactoring of CTF for this to be done first. The problem is that we can only handle one jdo-conf at CTF yet and all this tests requiere to change the configuration during the test.

Werner Guttmann - 05/May/05 05:56 AM
+1. Let's get this committed in time for 0.9.7. The more tests the better.

Question 1: Can you think about any 'dirty' way of allowing configuration of the RDBMS when running these tests, other than manually editing jdo-conf.xml files ?

Question 2: As we are adding more and more tests outside the CTF, I think we should add a test suite as well, and include all tests by definition. This way running these tests will be easier.


Ralf Joachim - 05/May/05 06:35 AM
to 1 above: The idea is to have a base configuration (the one we have yet), clone that one, change name and parameters (e.g. mapping) and use that one for the test.

to 2 above: I intend to continue my work on refactoring CTF and hope to be able to integrate the seperate tests until the release after 0.9.7. Until this time I wanted to leave the seperate tests.


Werner Guttmann - 05/May/05 07:37 AM
Alright. Go ahead ... .

Ralf Joachim - 07/Aug/05 04:48 AM
When trying to resolve this I was hit by 3 different things:

1) Current CTF do not allow to load differnt configurations. This can not be resolved without a bigger refactoring of the test framework therefore this need to be a standalone test for the moment.

2) There is another standanlone test at jdo.test1781 that tests to load a driver configuration with JDOConfFactory. I decided to add a new test to load datasource configuration with JDOConfFactoryto to this one.

3) The third thing appers to be the biggest one as the test always failed at setting the properties at datasource. The problem was that we used Castor XML to unmarshal the jdo-conf.xml file a second time to set the parameters at the datasource. Obviously we have a JdoConf instance as a in memory configuration but we don't have a jdo-conf.xml file when working with JDOConfFactory. The aproach to set properties at datasource could therefore never work with JDOConfFactory. I now directly use reflection to set the parameter on the datasource.

The patch have been tested with mysql using DHCP datasource and sapdb. Still tests with oracle are missing but this will be done when preparing the next release and I don't expect to see any problems there.


Ralf Joachim - 23/Aug/05 04:04 PM
I'm missing any comment why this issue has been reopend. The only problems that could have caused this are:

1) no exception thrown at a paramater that could not be set
2) it is not possible to work with in-memory JDO configurations according to the use of Unmarshaller to set the parameters at the datasource.

Both of this issues has been resolved while working at CASTOR-943. Therefore I'll close this one as duplicate.


Ralf Joachim - 23/Aug/05 04:15 PM
While working at CASTOR-943 I needed to change setting of parameters on datasource fromusing Unmarshaller to java reflections. according to this change this patch doesn't apply any longer. Having said that with CASTOR-943 also setting cache-scheme is possible with the syntax:

cache-scheme=1

still the syntax with using the CACHE_SCHEME_DYNAMIC constant of the oracle driver is not possible but IMO not required. I'll therefore close this issue as duplicate.