[
https://issues.apache.org/jira/browse/DERBY-1228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484563
]
Daniel John Debrunner commented on DERBY-1228:
----------------------------------------------
any testing could re-use the existing JUnit tests. It's fairly easy to write a
junit test runner that ran two suites in diffferent class loaders, say one with
10.2 jars and one with 10.3 jars. Hardest item might be finding the sub-set of
10.3 tests that succeed against 10.2.
In the future this would be easier as all releases will have a set of JUnit
based tests that work against that release.
On the jdbc driver class loader question, I don't think there are any problems.
The visibility of drivers is restrictec, to quote the javadoc for DriverManager:
"When the method getConnection is called, the DriverManager will attempt to
locate a suitable driver from amongst those loaded at initialization and those
loaded explicitly using the same classloader as the current applet or
application."
That's what Derby wants, if app A is using Derby 10.3 in one class loader and
app B using Derby 10.2 in another then they will see the version they require
through DriverManager.
I have a feeling though that the rule is not quite that simple, we have code
that successfully gets a connection to "jdbc:default:connection" from classes
loaded from installed jar files (which use their own classloader). I don't see
how that fits in with the above statement.
> 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.
