axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greg Truty" <>
Subject Config Provider changes
Date Mon, 22 Oct 2001 16:59:22 GMT
As a follow up, here is the updated design document and suggested changes
in order to implement the pluggable configuration provider solution.  It
was built against an early morning pull 10/22 from CVS.  I am also posting
some code for folks to try.  The functional tests work w/this.

The small design document incorporating changes from the last 10/16 IRC
chat are below.

ConfigProvider Scenarios

   - pure client (non-managed container)
   - pure server (non-managed server, like SimpleAxisServer)
   - client in managed container (like J2EE client)
   - server code (like servlet) in J2EE container (like web container)
   using container's server provider
   - server code (like servlet) in J2EE container (like web container)
   using container's client provider
   - server code (like servlet) in J2EE container (like web container)
   wanting to override container's server provider
   - server code (like servlet) in J2EE container (like web container)
   wanting to override container's client provider


   - introduce a pluggable solution for managing configuration information
   w/o requiring multiple implementations of the same classes (one version
   in one environment and another version in another)

Current Solution

   The current solution (as suggested below), hardcodes various providers
   and defaults to FileProvider which isn't pluggable and in fact, may not
   be able to run in an EJB container.

Possible Solutions

   - Use JNDI as a factory mechanism to get a global provider.
     Caveats -
         requires JDK 1.3, some performance overhead, possible classloader

     The usage of JNDI doesn't solve the problem all of the problems.  If
     the urlContext on the lookup has to instantiate an instance of the
     ConfigProvider, the ConfigProvider needs to be in the classloader
     path.  For example, if the container's implementation classes are not
     available on the classloader path, the implementation of the
     urlContext can't get access to the provider class (and hence, there
     are cases where this solution breaks down).

   - Use a system variable

   to set the default ConfigProvider (in the absence of one).  Caveats - In
   a managed container, affects the web apps ability to override the Axis
   Implementation for just one of the webapps (like a customer wanting to
   run their own version of Axis w/their own config provider).

   - Loading up a resource (eg., holding engine config
   information (like config provider class to be used).  Caveats - perhaps
   requires 2 reads (one to get the config provider and another to get the
   actual configuration information itself), classloader issue (provider
   must be available in the classpath - as specific in the JNDI caveats ).

   - Create a singleton object which allows a configurationProvider to be
   set upon it and used all the time.   Useful for managed containers to do
   so.  Caveats - doesn't allow it to be overridden in cases where  one of
   the implementations running within the container wants to use Axis.

   - Define a configurationProvider SPI and use the sun.misc.Service class
   in order to grab a service provider.  This involves creating a
   org.apache.spi.ConfigProvider abstract class that could be subclassed
   and a new ConfigProvider plugged in by following the ServiceProvider
   information in JDK 1.3 and the Jar File specification.  This is roughly
   similar to loading up a resource except that we are utilizing a
   mechanism provided by the JDK. Caveats - requires JDK 1.3 (if the
   official sun.misc.Service API is used).   This could be avoided by
   creating our own implementation that is similar to this (the batik
   project in Apache did this). The other caveat is some implied assumption
   on it's implementation behavior.  In playing w/it, it looked as though
   the providers are returned according to location on the classpath (which
   is probably desireable).  But, it's not explicitely stated as that's the
   behaviour within the specification.

Suggested Solution:

   To resolve this problem, in the most efficient way, a combination of the
   above methods which allows the flexibility needed/desired w/minimal

   There is an algorithm which could be used to determine the config
   provider.  The implementation/order of invocation is as follows:
     1. If a configuration provider is passed into the AxisEngine, ALWAYS
     use that.
     2. Otherwise, check to look a ServiceProvider has been provided.  If
     so, use that provider.  This way, the service provider can be
     overriden easily any anything willing to put itself in the classloader
     path first.This allows for something like a servlet to override the
     "containers" configProvider and use their own config provider.
     3. Default to File provider

   (I removed the option to use the singleton since it could be used as an
   implementation detail under the usage of the Service provider

   Provide our own org.apache.axis.util.Service class.
   For our axis.jar build, we can always take the default (3) unless a
   provider was passed in (like in SimpleAxisServer).

Work left to be done

 - I don't like our init() story for the engine.  I would rather it be a
bit more lazily and it was actually getting called twice in the old
implementation.  Plus, the exception handling needs to be cleaned up.
- I need to look at the server config being written out flag and my
(_client) flag to indicate client configuration defaults since I think they
can be merged.
- I want to rename the Configuration Provider to something like
org.apache.axis.spi.ConfigurationProvider.  What do people think?
- I need to think more about the administration of the model a bit...
(which is was my second issue that I postponed).

(See attached file:


Greg Truty
View raw message