[
https://issues.apache.org/jira/browse/DERBY-1228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Matrigali updated DERBY-1228:
----------------------------------
In the case where an appserver was already running multiple class loaders,
would a solution which just addressed an alternate way to load thouse
properties currently required to be system properties be sufficient? Would
there be any need for special Derby classloaders or any new classpath handling?
In this scenario it would be up to the application to insure the correct derby
classpath for each different classloader loading a different version of derby.
> Make it possible to run multiple instances of Derby within the same VM
> ----------------------------------------------------------------------
>
> Key: DERBY-1228
> URL: https://issues.apache.org/jira/browse/DERBY-1228
> Project: Derby
> Issue 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.
-
You can reply to this email to add a comment to the issue online.
