axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greg Truty" <>
Subject ConfigurationProvider
Date Wed, 10 Oct 2001 18:32:17 GMT

I've been taking a look at the configuration mechanism within Axis and I
have some questions on it's initial architecture and it's pluggability.
Therefore, let me explain what I see, describe possible problems w/it, and
suggest an alternative before I go off and do any work here to further
investigate/prototype (to see if people can tell me how wrong I really am).

Current configuration mechanism
A ConfigurationProvider is introduced w/2 sample implementations
(FileProvider and XMLStringProvider).  However, these implementations are
really dependent on a utility class ( which does the majority of
the work and essentially walk through the XML-based configuration and it
set's up the concrete instance of the AxisEngine that was passed into the
ConfigurationProvider.  It does so by calling into AxisEngine and
configuring the appropriate registries.  The AxisEngine itself doesn't know
about the configuration file but just the registries themselves that are
getting populated (Handler, Transport, Service, TypeMapping).

Problems w/this
Actually, I see 2 main problems w/this mechanism.
1) There are a couple of places in the code where we need to create
instances of these engines and we have hardcoded mechanisms of statically
creating a certain configuration provider.  I'm speaking of specifically
AxisServlet as well as ServiceClient.  The ServiceClient version is version
that I am most concerned with.  I don't see a easy mechanism to plug in a
different configuration provider.
2) The implementation of this ConfigurationProvider is tied very tightly to
the AxisEngine.  Looking at the interfaces of this provider, this portion
is unclear (as it's just essentially read/writeConfig).  There's no
information wrt. what the config contains.  Therefore, a new
ConfigurationProvider provider will have to understand the requirements of
what needs to be set on the AxisEngine (and saved away).

Alternative suggestion
To resolve 1) I think that instead of pushing the configuration provider to
the Engine, we should allow a mechanism for the provider to be retrieved
dynamically (as well as being pushed).  This is essentially what Berin was
suggesting when he was attempting to use the JNDI mechanism for doing this
sort of thing.  Essentially, the AxisEngine can postpone initialization
until it's first real method invocation (something that does something
w/the engine).  At that time, it could go configure itself.  If the config
provider is already attached to the engine, it uses that one.  Otherwise,
it goes through a lookup mechanism to find the config provider (and we can
simply use something like JNDI w/our own Axis URL schema mechanism to read
a properties file and get the configuration implementation, instantiate
that, and move forward).   I can do the same w/out JNDI but essentially, we
need to default to a factory mechanism for getting the provider (and JNDI
is a well known factory mechanism available in the JDK (at least 1.3 that

I am also thinking that this lookup mechanism is a way to attach new
implementations of other pluggable things.

To resolve 2) the other suggestion is that the ConfigurationProvider should
change to provide the appropriate populated registries that the AxisEngine
will use.   This isolates the administration of these registries to these
configuration providers (which is where it should be).  Intelligence could
be added to the configuration provider if it wants to rebuild these
registries each time (ie, reread the file, have some mechanism which checks
whether the file has changed, etc..).

Well, what do people think?


Greg Truty

View raw message