----- Original Message -----
Sent: Thursday, July 15, 2004 7:52
AM
Subject: [enhydra] Re: [dods]
DatabaseManager.ConfigurationDir setting
Hi,
If you want to use different dbVendor
configuration files for the same database in different applications, you can
add new dbVendor config file (just copy and rename existing configuration
file). You should add new config file in dodsConf.xml:
<Vendor
name="MyNewConfig">MyNewConfigConf.xml</Vendor>
and use
DatabaseManager.DB.example.ClassType =
"MyNewConfig"
in application conf file.
I hope it helps.
Regards,
Sinisa Milosevic,
Together Serbia
----- Original Message -----
Sent: Wednesday, July 14, 2004 6:24
PM
Subject: [dods]
DatabaseManager.ConfigurationDir setting
Hello all,
I've been using the
'DatabaseManager.ConfigurationDir' setting with Enhydra 5.1.9, which according to the documentation, is intended to
enable a particular Enhydra application to use a custom dodsConf.xml
file. However, even though the
'DatabaseManager.ConfigurationDir' setting is defined in an Enhydra
app's .conf file, I have found that this setting is actually
multiserver-wide - as in, if this setting is set in one Enhydra app, this
setting can be reset by another Enhydra app (either to a different value, or
back to the default value), wiping out the setting for the other Enhydra
app(s).
It seems that the cause of
this is that the database manager classes are getting loaded by the system
classloader, including the org.enhydra.dods.Common class
referenced in the StandardDatabaseManager class to set the
ConfigurationDir setting - the Common class stores this setting (and
others) in its static data, and since it's loaded by the system
classloader (in my case, an instance of sun.misc.Launcher$AppClassLoader)
rather than the Enhydra application classloader
(com.lutris.classloader.MultiClassLoader) this static data is shared across
all Enhydra applications under the multiserver.
A workaround would be to
use the same version of the dodsConf.xml for all apps
under the multiserver, but is there a better solution? Is there
any way to get the MultiClassLoader to load its own copy of the
org.enhydra.dods.Common class, or get the system classloader to forget about
its version? Is there anything in the
configuration that can cause this or similarly prevent this
setting from behaving in the manner it seems to have been
intended? If so, please let me know.
Thanks in advance,
Michael Strapp.