db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Xue (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1228) Make it possible to run multiple instances of Derby within the same VM
Date Wed, 14 Jun 2006 03:50:31 GMT
    [ 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:
For more information on JIRA, see:

View raw message