-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Glen,
Can you remember you raised the same question during the hackathon and I answered it :). Anyway here it is again. Client should see Options object as a means to pass params to Axis2 engine and not as a place holder for his properties. When he passes that to MessageContext, we keep that underneath the message context as we do not want the overhead of copying everything to a new data structure inside the message context. Since this options object will be anyway there inside the message context, and since it can store properties, we didn't put another object to message context to store properties. We re-used the same options object. Yes, this is a deliberate design decision. IIRC, me and Sanjiva (Deepal also, IIRC) had a long chat on this, sent a proposal and did that. See, what you are saying is in fact asking to copy the properties of the options object to message context property object, leaving the room for the user to re-use it. What we have done was asking the user to copy it himself, if he needs to re-use it, but achieving possible performance AND memory gains inside the engine. Yes, it is by design and I don't see any issue with that. It is the way you see it. The only problem is I am not sure we have written down this somewhere, other than in a mail thread :(. Ruchith, sorry for hijacking your thread. Will try to answer it in the next email :) Thanks, Chinthaka Glen Daniels wrote: > David Illsley wrote: >> Yep, properties which are not copied to the operation context in the >> outflow will not be available on the inflow message context (unless >> you walk up the tree and find the related message context). > > It might be nice to have a separate API for setting properties in an > OperationContext-accessible way, much as Options automatically makes > them available on the MessageContext. > > Er.. I just noticed that when you set properties on the MessageContext > they actually get set on the Options object?? This behavior has > apparently been there a while - I'm gonna go back and try to find the > threads around it, but this seems stunningly wrong to me(?). I thought > the Options object was one you were supposed to be able to reuse between > calls, where you store the stuff that you, the application (client > usually), care about. Right now it looks like if a Handler sets a "foo" > property on the MC, that property value is going to be persisted across > any invocation using that Options object (and also kept around > unnecessarily if it was a per-MC transient property).... Whaa? > > --Glen > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGfv5fjON2uBzUhh8RAuPzAKCHAQuUu+080G229N4oJCY2mtu/UACdGDyo biuRMTdXmMP4OKyMI2O26mk= =1ZZk -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
