Re: [dods] DatabaseManager.ConfigurationDir setting

["Sinisa Milosevic" <sinisa@xxxxxxxxxxxxx>]

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 -----

From: Michael Strapp

To: Enhydra Mailing List ; DODS Mailing List

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.