We have two types of configuration info... 1. That stored in the client-config.wsdd/server-config.wsdd 2. Various 'overrides' that are set as system properties.
I'd like to: a. introduce a level of indirection for current code that gets system properties. Chang all calls to go through an org.apache.axis.utils.AxisConfiguration class (other name suggestions are welcome). b. change AxisConfiguration class to: i) first check system property (preserve current override behavior that testers like) ii) check in axisConfig.properties file. One of our goals is to package AXIS (unchanged!) into our system runtime with overrides we find necessary for our integration. Yet we would like to allow customers to deploy applications containing axis.jar, and let the 'application level' axis entirely override the 'system/runtime version' (i.e. falls back to using the config file in axis.jar). Thus I'd like the classLoader to look for axisConfig.properties in the following order: 1. axisConfig.properties in application, (not in axis.jar) 2. axisConfig.properties (empty, no overrides) in axis.jar, installed as part of an application. 3. axisConfig.properties (contains integration overrides), in our webservices system runtime 4. axisConfig.properties (empty, no overrides) in axis.jar, installed in system runtime. Notes: - Having an 'empty' override file in axis.jar allows an application+axis.jar install to fall back to defaults. The alternative of having all default behavior explicitly specified in the property file (instead of in code) means keeping 'override' files up-to-date with changes we make to the defaults... not good. - (3) will override (4), so (4) is never "seen". I'd like to avoid dependencies on order of classpath entries. Any bright ideas on how to accomplish the order above using the existing class loaders (thread-context versus application [right name?])? ******************************************* Richard A. Sitze [EMAIL PROTECTED]
