[ http://issues.apache.org/jira/browse/DERBY-1228?page=comments#action_12416117 ]
Gary Xue commented on DERBY-1228: --------------------------------- I second this feature request. Not allowing multiple Derby system instances (and by extension, not allowing different versions of the Derby JAR files) to co-exist in the same JVM has now become a big headache for us working on the Eclipse projects. (Several Eclipse subprojects now use Derby). Derby would not become a viable solution for embedded database in a Server or Eclipse-based application unless this issue is resolved. It is impossible to require all extension or plugin providers to use the same (or compatible) versions of Derby. > Make it possible to run multiple instances of Derby within the same VM > ---------------------------------------------------------------------- > > Key: DERBY-1228 > URL: http://issues.apache.org/jira/browse/DERBY-1228 > Project: Derby > Type: New Feature > Components: Services > Reporter: David Van Couvering > > Make it possible to run multiple instances of Derby within the same VM, each > with its own derby.system.home, separate configuration parameters, and even > different versions of Derby jar files. I haven't looked at this carefully, > but at first glance I think this would require (a) refactoring Derby code to > get all configuration from a configuration API rather than directly from > system properties (b) write a configuration API/class that supports a > properties file as well as system properties (in the future this class could > also work with JMX) (c) the ability to specify the derby.system.home and a > classpath as a DataSource property (d) a Derby classloader that loads Derby > jar files from the classpath specified on the DataSource -- 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
