[EMAIL PROTECTED] wrote: > > BTW, where would your application run? I am assuming it is outside of > any managed environment like application server. >
I think this use-case is applicable to both raw J2SE applications and also those running inside an application server. For a raw J2SE application it may well be that there are different components inside the application that have been written against different versions or even just different configurations of Derby. For example, consider Eclipse where two different plugins both want to use a database; or Maven, where two plugins or something simple like two unit tests want different database configurations. Both these environments have classloading that can be used to load different versions of Derby but that's not going to solve the System properties problems. The same problem applies in an application server as well. Multiple end-user applications may, assuming the appropriate permissions are granted, want to access separate databases. Even loading them as J2CA connectors will run into the properties problems. In an ideal world, I would like to be able to specify all the properties for a Derby engine (rather than a database) during some explicit startup phase. For example, in a J2CA environment it could (portably) be done during bootstrap of the ResourceAdapter; in Eclipse or Maven it could be done as part of plugin initialization; in JUnit it could be done during fixture initialization. This could also be used by the standalone network server to start its embedded engine. I can envision the API for this as a simple JavaBean with setters for the various properties and start/stop methods to control the engine. Compatibility with existing applications could be maintained by simply starting a singleton engine in the Driver having set its bean properties from the current system properties; this is very similar to how the Monitor is bootstrapped now when the first connection is made. -- Jeremy
