This seems similar (at least in my head) to DataSourceFactory here:
http://mail-archives.apache.org/mod_mbox/db-derby-user/200511.mbox/browser
As Dan said, I think we need to be careful not to confuse the two
mechanisms for setting properties. However, I think there is a clear
separation between properties used to configure an engine and those used
to configure a datasource used to access the engine:
* properties on DerbySystem/DataSourceFactory that are used to configure
the underlying engine itself (such as location of the error log)
* properties on the DataSource implementation that configure how the
user is going to connect to that engine
In DataSourceFactory, the getFactory() method took a uri that identified
the desired implementation. The resulting factory could then be
configured with implementation specific properties (in Derby's case,
engine properties) before being used to create a DataSource. The
resulting DataSource can then be configured as usual.
For example,
DataSourceFactory systemA = DataSourceFactory.getFactory("derby:10.2");
DataSourceFactory systemB = DataSourceFactory.getFactory("derby:11.1");
systemA.setProperty("derby.system.home", "/home/dbA");
systemA.setProperty("derby.error.log", "/home/dbA/derby.log");
systemB.setProperty("derby.system.home", "/home/dbB");
systemB.setProperty("derby.error.log", "/home/dbB/foo.log");
DataSource dsA = systemA.getDataSource();
DataSource dsB = systemB.getDataSource();
BeanUtils.setProperty(dsA, "databaseName", "wombat");
Connection connA = dsA.getConnection();
BeanUtils.setProperty(dsB, "databaseName", "wombat");
Connection connB = dsB.getConnection();
--
Jeremy
David W. Van Couvering wrote:
> I also wanted to share an idea to help move us towards the larger
> problem supporting multiple Derby systems within the same VM (currently
> that's not possible).
>
> The idea is that we have a new public class called DerbySystem that's in
> it's own package. This is basically a data source factory for a given
> Derby system, each with its own classloader. So in the same VM I could
> do something like
>
> // Note the properties could be loaded from a config file rather
> // than hardcoded in the source
> Properties propsA = new Properties();
> propsA.setProperty("derby.system.home", "/path/to/system/a");
> propsA.setProperty("derby.system.classpath",
> "/home/derby/10.1/derby.jar");
> DerbySystem systemA = new DerbySystem(propsA);
>
> Properties propsB = new Properties();
> propsB.setProperty("derby.system.home", "/path/to/system/b");
> propsA.setProperty("derby.system.classpath", "/home/derby/10.2/derby.jar");
> DerbySystem systemB = new DerbySystem(propsB);
>
> DataSource dsA = systemA.getDataSource("jdbc:derby:wombat;create=true");
> DataSource dsB = systemB.getDataSource("jdbc:derby:wombat;create=true");
>
> Connection connA = dsA.getConnection();
> Connection connB = dsB.getConnection();
>
> Note that for this to really work we need to fix Derby so that there are
> no hardcoded uses of system properties, but instead all code uses a
> service to obtain configuration properties for a given system.
>
> David
