axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <>
Subject RE: ConfigurationProvider
Date Thu, 11 Oct 2001 19:20:35 GMT

Hi Greg!

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

Yup - this was never finished, but planned.  Essentially you could pretty
easily add a setConfigProvider(ConfigurationProvider) API to ServiceClient.
The purpose of the XMLStringProvider was to allow "hard coded"
configurations for particular applications (clients in particular) which
would never touch the file system.

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

Right.  This is sort of a religious debate, and one which I don't have a
clear answer for.  It seems like the two sides are either:

1) "Engine-centric" config.  This is the model we have now - you have APIs
on the engine to allow registering Handlers, Transports, TypeMappings, and
Services, and you pass an engine instance into a piece of code that knows
how to deploy stuff using those APIs.

2) "Registry-centric" config.  The other approach seems to be to move all
the configuration/deployment info into the ConfigurationProvider itself, and
let the engine ask the ConfigurationProvider for things with apis like
configProvider.getService(name).  This moves the details of the
configuration/deployment structure deeply into the ConfigurationProvider

Fact is, configuration *is* tied very tighly to the AxisEngine one way or
the other.

> 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
> is)).

Yes, this seems like a great idea, though the init process could still
happen at construction time without much trouble, I think.  It's just a
matter of changing the algorithm to use (in this order) 1) any directly set
ConfigurationProvider, 2) any ConfigurationProvider supplied by a factory
which is pointed to by a system property, or 3) a default
ConfigurationProvider.  I'm definitely +1 to this.

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

Yep, this would be an option.  My only problem with it is that it actually
forces a tighter coupling between the engine and the ConfigurationSupplier -
if something needs to change, we'd need to tweak the interface and all
implementations.  By just passing the Engine in, new versions of
ConfigurationSuppliers could utilize new Engine APIs/features without having
to rebuild the old ones.  Maybe not such a big deal, and certainly dealable
with by having both styles - the ConfigurationSupplier becomes the source
for the registries, but it also gets to touch the engine in any way it wants
at init time.


View raw message