You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Srinath Perera <he...@gmail.com> on 2006/02/24 15:36:58 UTC

[Axis2][RFC]Axis2 and static variables/System properties

Hi All;

This occurred to me when I working on a application that uses Axis2.
The application do a another Web Service invocation from the Handlers
(To get the capability tokens). I need the main invocation, and the
invocation from the Handler to use different Axis2 repositories.

If we set a system property to pinpoint a repository, both will be
loaded with same repository. Only way to fix it is to redefine the
system properties before each invocation .. which lead to horrible
code.

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

Thanks
Srinath




--
============================
Srinath Perera:
   http://www.cs.indiana.edu/~hperera/
   http://www.bloglines.com/blog/hemapani

Re: [Axis2][RFC]Axis2 and static variables/System properties

Posted by Srinath Perera <he...@gmail.com>.
> If you really want to use the simplest ServiceClient API (where we auto
> create a dumb service underneath) then you can still do that .. pass
> null as the 2nd arg. So we already have the capability you're looking
> for.

Oops, sorry I should have read the code. I do not notice I can pass null

> I'm still not convinced your scenario is very common: the user is
> advanced enough to create their own repo etc., but only wants to use the
> dumb anonymous service? Doesn't compute for me. But hey, its
> supported :).

At the client side service hardly matter! one can engage the modules
at the client API. But two repositories will be very common if specs
like RM/Secure conversation/Trust ever come to day to day use.

On the other hand if the client is ever serious about the performance
he better use one repository. One do not need to load complete
repository per each invocation (do we recycle same repository for
multiple instance of Service Client? )

Sorry for messing it up, I should have notice I can pass null as a argument :)
Thanks very much

Srinath

Re: [Axis2][RFC]Axis2 and static variables/System properties

Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Sat, 2006-02-25 at 18:14 +0000, Steve Loughran wrote:
> 
> Look at this way: why do I have to go to the effort of creating all the 
> (many) service declarations when all I want is to send XML documents to 
> a URL I've chosen? Its pretty painful setting up a serviceclient by hand.

Really?? It is:

ServiceClient sc = new ServiceClient ();
sc.getOptions.setTo (new EndpointReference ("myaddress"));
sc.fireAndForget (the-omelement-to-send);

Do you consider that hard? Please suggest how we can improve it!

Sanjiva.


Re: [Axis2][RFC]Axis2 and static variables/System properties

Posted by Steve Loughran <st...@apache.org>.
Sanjiva Weerawarana wrote:
> On Fri, 2006-02-24 at 19:15 -0500, Srinath Perera wrote:
> 
>>If we had  constructor
>>public ServiceClient(ConfigurationContext configContext) throws AxisFault
> 
> 
> Note that this idea is generally nonsensical: you want a client for a
> service but don't say for what service. However, we do have the simplest
> level of that auto supported already thru the no args constructor and
> the approach indicated below.
> 
> 
>>that would have been true, but what we have is
>>
>>public ServiceClient(ConfigurationContext configContext,              
>>           AxisService axisService) throws AxisFault
> 
> 
> If you really want to use the simplest ServiceClient API (where we auto
> create a dumb service underneath) then you can still do that .. pass
> null as the 2nd arg. So we already have the capability you're looking
> for.
> 
> I'm still not convinced your scenario is very common: the user is
> advanced enough to create their own repo etc., but only wants to use the
> dumb anonymous service? Doesn't compute for me. But hey, its
> supported :).
> 
> 
>>I should create a repository, then a AxisService, add the operations
>>and then only call constructor. I can do that, but a new uesr would
>>not get it that easily. Can we add the first costructor?

Look at this way: why do I have to go to the effort of creating all the 
(many) service declarations when all I want is to send XML documents to 
a URL I've chosen? Its pretty painful setting up a serviceclient by hand.




Re: [Axis2][RFC]Axis2 and static variables/System properties

Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Fri, 2006-02-24 at 19:15 -0500, Srinath Perera wrote:
> If we had  constructor
> public ServiceClient(ConfigurationContext configContext) throws AxisFault

Note that this idea is generally nonsensical: you want a client for a
service but don't say for what service. However, we do have the simplest
level of that auto supported already thru the no args constructor and
the approach indicated below.

> that would have been true, but what we have is
> 
> public ServiceClient(ConfigurationContext configContext,              
>            AxisService axisService) throws AxisFault

If you really want to use the simplest ServiceClient API (where we auto
create a dumb service underneath) then you can still do that .. pass
null as the 2nd arg. So we already have the capability you're looking
for.

I'm still not convinced your scenario is very common: the user is
advanced enough to create their own repo etc., but only wants to use the
dumb anonymous service? Doesn't compute for me. But hey, its
supported :).

> I should create a repository, then a AxisService, add the operations
> and then only call constructor. I can do that, but a new uesr would
> not get it that easily. Can we add the first costructor?

See above; its already there.

Sanjiva.


Re: [Axis2][RFC]Axis2 and static variables/System properties

Posted by Srinath Perera <he...@gmail.com>.
If we had  constructor
public ServiceClient(ConfigurationContext configContext) throws AxisFault

that would have been true, but what we have is

public ServiceClient(ConfigurationContext configContext,              
           AxisService axisService) throws AxisFault

I should create a repository, then a AxisService, add the operations
and then only call constructor. I can do that, but a new uesr would
not get it that easily. Can we add the first costructor?

Thanks
Srinath

On 2/24/06, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> Come on Srinath .. its ONE more line of code:
>
> - create the repo
> - create the config context using ConfigurationContextFactory
> - now create the ServiceClient
>
> I hardly see that being hard .. and its not a common case anyway. If you
> have your own repo then its unlikely its something you use for exactly
> one service client - so most likely you'll create your config from the
> repo and re-use the config context.
>
> I don't see the need to make ServiceClient more complex/flexible.
>
> Sanjiva.
>
> On Fri, 2006-02-24 at 11:46 -0500, Srinath Perera wrote:
> > Thanks Glen !!
> >
> > > ServiceClient should definitely (IMO) have a way of providing a
> > > Repository (i.e. an abstract repository API that only cares about the
> > > Objects, not the XML) via the API.  Then you can create a FileRepository
> > > configured the way you want it, and pass that in:
> > >
> > > FileRepository repo = new FileRepository(myPath);
> > > ServiceClient client = new ServiceClient(repo);
> >
> > yes, this exactly what I want to do !!
> >
> > But now  ServiceClient(ConfigurationContext,AxisService)  need user to
> > create ConfigurationContext ,AxisService, add Operations to service
> > ect .. which is hardly a easy way to override!
> >
> > >  then of course I could also programatically do:
> > >
> > > CustomRepository repo = new CustomRepository();
> > > repo.deployService("test", myClass);
> > > repo.deployModule("addressing", addrModule);
> > > ...
> > > ServiceClient client = new ServiceClient(repo);
> >
> > :D cool
> >
> > Thanks
> > Srinath
> >
> >
> > --
> > ============================
> > Srinath Perera:
> >    http://www.cs.indiana.edu/~hperera/
> >    http://www.bloglines.com/blog/hemapani
>
>


--
============================
Srinath Perera:
   http://www.cs.indiana.edu/~hperera/
   http://www.bloglines.com/blog/hemapani

Re: [Axis2][RFC]Axis2 and static variables/System properties

Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Come on Srinath .. its ONE more line of code:

- create the repo
- create the config context using ConfigurationContextFactory
- now create the ServiceClient

I hardly see that being hard .. and its not a common case anyway. If you
have your own repo then its unlikely its something you use for exactly
one service client - so most likely you'll create your config from the
repo and re-use the config context.

I don't see the need to make ServiceClient more complex/flexible.

Sanjiva.

On Fri, 2006-02-24 at 11:46 -0500, Srinath Perera wrote:
> Thanks Glen !!
> 
> > ServiceClient should definitely (IMO) have a way of providing a
> > Repository (i.e. an abstract repository API that only cares about the
> > Objects, not the XML) via the API.  Then you can create a FileRepository
> > configured the way you want it, and pass that in:
> >
> > FileRepository repo = new FileRepository(myPath);
> > ServiceClient client = new ServiceClient(repo);
> 
> yes, this exactly what I want to do !!
> 
> But now  ServiceClient(ConfigurationContext,AxisService)  need user to
> create ConfigurationContext ,AxisService, add Operations to service
> ect .. which is hardly a easy way to override!
> 
> >  then of course I could also programatically do:
> >
> > CustomRepository repo = new CustomRepository();
> > repo.deployService("test", myClass);
> > repo.deployModule("addressing", addrModule);
> > ...
> > ServiceClient client = new ServiceClient(repo);
> 
> :D cool
> 
> Thanks
> Srinath
> 
> 
> --
> ============================
> Srinath Perera:
>    http://www.cs.indiana.edu/~hperera/
>    http://www.bloglines.com/blog/hemapani


Re: [Axis2][RFC]Axis2 and static variables/System properties

Posted by Srinath Perera <he...@gmail.com>.
Thanks Glen !!

> ServiceClient should definitely (IMO) have a way of providing a
> Repository (i.e. an abstract repository API that only cares about the
> Objects, not the XML) via the API.  Then you can create a FileRepository
> configured the way you want it, and pass that in:
>
> FileRepository repo = new FileRepository(myPath);
> ServiceClient client = new ServiceClient(repo);

yes, this exactly what I want to do !!

But now  ServiceClient(ConfigurationContext,AxisService)  need user to
create ConfigurationContext ,AxisService, add Operations to service
ect .. which is hardly a easy way to override!

>  then of course I could also programatically do:
>
> CustomRepository repo = new CustomRepository();
> repo.deployService("test", myClass);
> repo.deployModule("addressing", addrModule);
> ...
> ServiceClient client = new ServiceClient(repo);

:D cool

Thanks
Srinath


--
============================
Srinath Perera:
   http://www.cs.indiana.edu/~hperera/
   http://www.bloglines.com/blog/hemapani

Re: [Axis2][RFC]Axis2 and static variables/System properties

Posted by Glen Daniels <gl...@thoughtcraft.com>.
Srinath Perera wrote:
> 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)

ServiceClient should definitely (IMO) have a way of providing a 
Repository (i.e. an abstract repository API that only cares about the 
Objects, not the XML) via the API.  Then you can create a FileRepository 
configured the way you want it, and pass that in:

FileRepository repo = new FileRepository(myPath);
ServiceClient client = new ServiceClient(repo);

and then of course I could also programatically do:

CustomRepository repo = new CustomRepository();
repo.deployService("test", myClass);
repo.deployModule("addressing", addrModule);
...
ServiceClient client = new ServiceClient(repo);

> 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*!

+1 :)

There are actually multiple levels of configuration here, too.  The 
first is "which Repository class/factory should I use".  The second is 
dependent on the particular class chosen, and involves configuring that 
type of repository.  So the first choice is, for instance, 
"FileRepository", and then that repository has its own configuration 
scheme for figuring out the path - you can either pass it manually as 
above, look in a static/system property, etc....

--G

Re: [Axis2][RFC]Axis2 and static variables/System properties

Posted by Srinath Perera <he...@gmail.com>.
Hi Glen;

I agree 100% on
<snip>
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.
</snip>

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*!

Thanks
Srinath



On 2/24/06, Glen Daniels <gl...@thoughtcraft.com> 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:
   http://www.cs.indiana.edu/~hperera/
   http://www.bloglines.com/blog/hemapani

Re: [Axis2][RFC]Axis2 and static variables/System properties

Posted by Glen Daniels <gl...@thoughtcraft.com>.
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