views:

45

answers:

4

I am writing an eclipse RCP app and I am trying to use a separate db for tests to prevent corrupting my production db. During the setup of the test db i need to execute an sql file to fill it with test data.

Is there a way to tell the app to use a different db and execute a specific sql script (maybe via launch properties or maybe fragments or sth else)?

Thank you

A: 

For an RCP I usually use some type of property file. Within it I'd specify things such as the DB to use and startup script (if necessary). This approach will be well worth it as your application grows.

SOA Nerd
and your persistence bundle reads this prop file at startup, i suppose? that would work, but one has to edit or switch the prop file for production/test launches which is what i am trying to avoid. What i would like to do is to generate separate launch or product files to specify the props or the according fragments "once and for all"
kostja
+1  A: 

Your application will accept arguments like the Eclipse executable. You can specify the arguments in the ini file of your app (in Eclipse it is eclipse.ini, you can rename it for your app) in the form of

-vmargs
-Dkey=value

These values can be read using System.getProperty

On some platforms you should be able to accept these arguments from the command line as well.

zvikico
This one would work too, even simpler than a config file,a syou dac define the args in the product. The only thing i dislike about it is rather an aesthetic one, matter of opinion. I would like a more "air-tight" solution, relying on RCP tech only. A valid answer though
kostja
+1  A: 

I found and am using a different approach now, more RCP-ish IMHO. I define a fragment to override the database props and replacing a dummy query file in the host plug-in. Then i define two features - one for the testing with the fragment, and the production feature without the fragment. And then use the features in different products - one for production, one for testing. Works fine

kostja
+1  A: 

Sounds like a perfect use-case for OSGi Services.

Neil Bartlett
sounds interesting. could you please elaborate?
kostja
Develop a bundle that connects to a database, does some initialisation (e.g. executes some SQL if necessary) and then publishes as a service under the javax.sql.DataSource interface. Now your application bundle can access the database without caring whether it is production or test. To switch, deploy a different version of the database connector bundle (or configure it with the standard Config Admin service).
Neil Bartlett