axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard Sitze" <>
Subject [axis] Configuration properties via system properties
Date Wed, 22 May 2002 20:07:34 GMT
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

b. change AxisConfiguration class to:
i) first check system property (preserve current override behavior that
testers like)
ii) check in 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 in the following order:

1. in application, (not in axis.jar)
2. (empty, no overrides) in axis.jar, installed as
part of an application.
3. (contains integration overrides), in our
webservices system runtime
4. (empty, no overrides) in axis.jar, installed in
system runtime.

- 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  

View raw message