axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <>
Subject Re: [Axis2] Client API - Handling properties that are set via options
Date Tue, 06 Dec 2005 12:11:41 GMT

we now set up 2 Options() one for per stub and one per operation and
the properties set in stub override the properties generated by


On 12/6/05, Tom Jordahl <> wrote:
> Eran,
> I don't know if you have already resolved this issue, but I think we
> should make a copy (option #1) of the hash map.
> This is the safest and most conservative thing to do, and I think it
> will prevent unpleasant surprises for any users of the API.
> Sometimes you just have to do the work, even if it might take a few more
> machine cycles.  That is what HotSpot is for.  :-)
> --
> Tom Jordahl
> -----Original Message-----
> From: Eran Chinthaka []
> Sent: Thursday, December 01, 2005 11:54 AM
> To:
> Subject: [Axis2] Client API - Handling properties that are set via
> options
> We are in the process of doing some changes to the client api.So this is
> the start of documenting them.
> This is all about the property bag that can be accessed via setProperty,
> getProperty in Options.
> When we set some properties in to the Options, that will ultimately end
> up in operation context. Basically, we passed the reference of the hash
> map in the options, to the operation context. So if one uses the same
> options to call some other service, the option object shares the map of
> properties. So in some cases, if one party changes a property, that will
> be reflected in the other.
> So we have two options.
> 1. to "copy" each and every property from the client properties hash map
> to the context properties.
>  - the problem with this is, this will affect the performance. Some time
> user might need not want to copy those information as he may be using
> different calls or he may wait till this invocation finishes.
> 2. ask the user to clone the options, if he needs to use the same
> options for multiple invocations.
>  - this is bit of problematic as far as the usability of the api is
> concerned.
> 3. the middle approach : set a flag in the properties itself. So the
> default is we do not copy. But we pass the pointer of the hash map as it
> is. But if the flag is set, we copy each and every property. So I'd say
> its sort of a compromise.
> -- Chinthaka

Davanum Srinivas :

View raw message