Bug 369243

Description Justin Spadea 2012-01-20 10:02:37 EST

Every data source implementation is different and requires different parameters. Some will have a "user" parameter, others will call it "username"; some will let you set the JDBC URL, others force you to specify the individual pieces (which differ from class to class). The only way would could support any data source class would be to have the user tell us every property name and its value, in a table. Rather than force them to do a lot of work, the test server has the following support (already implemented):

1. If org.apache.tomcat.dbcp.dbcp.BasicDataSource is present, we'll use it. This class supports connection pooling and is very fast on subsequent connections.

2. The fallback is our own very, very simple implementation called SimpleDataSource. It has no connection pooling, just invokes DriverManager.getConnection() under the covers. We can add connection pooling in the future, but for now it just "gets the job done" so that JNDI can be used by the test server.

This work item is to provide some indication to the user about BasicDataSource. The test server should be updated to check for a Tomcat runtime and add it to its classpath if it finds it. This way all the user needs to do is define the Tomcat runtime and they have connection pooling. We can make the test server's preference page indicate whether connection pooling is available, and if it's not we can provide a button that pops up the New Runtime wizard, preferably with everything except tomcat filtered out. We can also have the test server write a warning to the console if connection pooling is not available.

Since what we already have "works", this is not a must-have for 0.8, but we should try to fit it in. At the very least we could write a blog post about how to enable it (right now you must add the Tomcat runtime to the project running the test server).