axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Srinath Perera" <>
Subject Re: [Axis2][RFC]Axis2 and static variables/System properties
Date Fri, 24 Feb 2006 16:16:31 GMT
Hi Glen;

I agree 100% on
Statics/system properties are fine ways to default configurations, as
long as there are *easy-to-use ways of overriding those defaults* for
particular cases.

In the particular example I motioned ServiceClient do not have a way
to provide a repository pth from the API. And when I asked for it .. I
am instructed to use system properties. (To use the provided api I
should create ConfigurationContext add Service, Operations ..ect 
which is not good for non-axis2 developer)

But if I use the system properties they get in each others way because
I have two configurations.

Let me revise my proposal :)

Static things should not be used except for providing default
configurations and there should (or must)  be a *easy-to-use ways of
overriding those defaults*!


On 2/24/06, Glen Daniels <> wrote:
> Hi Srinath!
> Srinath Perera wrote:
> > I think most of the future scenarios for Axis2 will involve this kind
> > of scenarios where different configurations are used for different
> > invocations. If we are heading to support them .. I think it is better
> > to stay away from static things like static variables and System
> > Properties ..etc
> >
> > We have argued on this point before .. But I thought it is better to
> > discuss it clearly so we all are clear on our policy. Hopefully this
> > mail will lead to a conclusive discussion .. (Either we agree on a
> > policy that static things not used or I get convinced other wise ( or
> > learn not to try to press this over and over again ;) ) )
> Statics/system properties are fine ways to default configurations, as
> long as there are easy-to-use ways of overriding those defaults for
> particular cases.
> The answer, of course, is that you do BOTH.  This is a solved problem -
> look at log4j configurators, or Spring, or any number of other
> frameworks which require configuration.  You have a clearly defined
> hierarchy of places to get configuration from (passed directly, use a
> factory, look for files various places, etc), and the most-specific one
>   wins.
> This allows specific contextual usages of the system (Axis2 embedded on
> a cellphone, Axis2 running as a user process, Axis2 running as a system
> service, etc) to get their configuration in appropriate ways.
> To be a little more specific, something like this:
> 1. If a specific configuration was passed directly, use it.
> 2. Look in TLS for a thread-specific configuration factory.
>     If there, use it.
> 3. Look in a static var somewhere for a configuration factory.
>     If there, use it.
> 4. Look in a system property for a config factory classname.
>     If there, use it.
> 5. Default to FileConfigurationFactory.
> --Glen

Srinath Perera:

View raw message