David Van Couvering wrote:
Jeremy Boynes wrote:
[snip]
AIUI there are two levels of configuration: system and database
* system configuration comes from system properties and
classloader resources
* database configuration overrides based on values from derby.properties
in the database directory
My investigation says there are three levels:
- System properties set through the command line or programmatically
- Database properties
- Properties set in derby.properties
What do you mean by "classloader resources?"
I meant things loaded as resources such as modules.properties
These come from the codebase (the jar files) not from the environment
(properties or the disk image of the db)
<snip/>
Finally, the derby.properties file for a system must be located in the
directory specified by derby.system.home system property. So again
there is no way to have more than one system configuration per VM, as
far as I can tell.
It seems to me this could be easily fixed in the following way:
- derby.properties is loaded by the classloader
- derby.system.home can be specified in derby.properties
This would allow you to have multiple Derby system instances in the same
VM, right? Is that what you meant by a "per-classloader static property
map" below?
I meant that rather than looking up property values from
java.lang.System it would be simple to modify the code to use a
PropertyManager that would keep the properties in a static. Given
statics are local to the ClassLoader, different versions of the engine
loaded by different ClassLoader's would have different properties.
There would need to be a way to initially populate each copy of the map;
for simple installations it could work as now by cloning the system
properties, for more complex installations some other mechanism could be
used (e.g. config-values in ra.xml if the engine was deployed as a
ResourceAdapter).
I don't think loading from the codebase using ClassLoader.getResource()
(as is done for modules.properties) will be flexible enough; I wasn't
sure if that is what you meant by "loaded by the classloader"
<snip/>
I have also wondered about providing an injection mechanism for stored
procedure implementations where the engine would inject a DataSource
into the class or instance that could be used instead of DriverManager
to obtain the connection. This is obviously an extension to the spec
but might be friendlier.
Using a DataSource does sound friendlier, but it is an "extension" as
you say. And one of the "prime directives" of Derby as I understand it
is to stay with the standards, so that migration to "other databases" is
possible and customers feel they aren't locked in. How would you
reconcile this?
From my perspective, if there is a standard way of doing something then
we should implement it. If there are limitations with the standard
approach that we can improve then we add extensions. The standards
define the lowest common denominator that users can use to ensure
portability; extensions provide benefit to users at the cost of
potential lock in. Let people choose how much lock they want.
--
Jeremy
