Hi Chinthaka:
Sorry for the long message. The "executive summary" is that I'd like to
separate out the Options property store from the MC property store, so
that people can reuse Options objects, avoiding the need to clone them
and also avoiding cluttering them. I've implemented this and it builds
clean. OK....
Eran Chinthaka wrote:
IIRC, in this thread I mentioned that Options is per invocation. So if
user wants to do multiple invocation with the same Options object then
he needs to clone or copy it to another object.
Oh! Is that documented somewhere? I guess I'd expect to see something
that important in the JavaDoc for Options, or the user guide....
So let's go with the idea that the intent of Options is NOT in fact to
be reusable. If that's the case, then IMHO it's still not designed very
well. Thoughts:
* MessageContext *is* the state-handling object associated with a given
message. If we designed Options purely as an API convenience (and
really, take a look at the current API for Options - is it really
simple?), it would have been much nicer to just supply an interface and
leave it as one object (the MC). What we have now is a "false" split
into two objects, it seems to me.
* Why is MessageContext bothering to subclass AbstractContext, but not
use the actual context-storing functionality of AC? It's not "really"
an AbstractContext, is it?
* We confuse what's "in" the MessageContext with what's in the Options.
Example - AddressingOutHandlerTest uses mc.setProperty() to set
something, and the actual AddressingOutHandler expects to use
Options.getProperty() to read it. Do you think this kind of thing makes
sense / feels natural / avoids errors?
* Options seems to really want to be associated with an Operation, not a
Message.... it's got stuff like listeners, transport in AND out, etc.
In fact originally it looks like it was associated with the
OperationContext, not the MessageContext...? See this thread:
http://marc.info/?l=axis-dev&m=113341827426019&w=2
I think things have evolved somewhat strangely....
If you want to do multiple invocations, clone the options object. I am
sorry I can not see a problem in that.
> [...]
Why do you think Options object will be there. After an invocation user
dumps it and uses another options object.
Well, the problem with cloning it is that it's kind of a pain (which you
mentioned in the thread referenced above :)). Users of Axis1 are used
to the idea that you can set up a Call, set a bunch of properties on
that Call, and then reuse it a bunch of times, with those properties
available in the MessageContext on each invocation. It would be nice to
have a similar ability in Axis2...
And in fact, it looks like a ServiceClient DOES by default re-use the
Options object! If I go:
ServiceClient c = new ServiceClient();
c.setOptions(opts);
c.sendReceive();
c.sendReceive();
...
it re-uses the options, no?
So this is the summary of what I am trying to say.
- - Options object (eventhough the name is bit weird. Dr. Sanjiva can you
remember we discussed that the name is not appropriate to that object?)
is per invocation only.
- - if you want to do multiple invocations, you need to either create a
new Options object or clone the previous one.
OK, I understand but do not agree. ;)
In this approach, there is no un-necessary copying of properties or
within the execution path.
According to what you're saying, you have to copy properties between
your Options object for invocation N to a new Options object for
invocation N+1, don't you? That seems unnecessary to me. :)
Glen, I apologize if I still not got the point that you are trying to
make here. That may be why I am still thinking current impl is correct.
The point, as I hope I've clarified by now, is that the current
implementation is flawed in one of two ways - either the Options object
really is intended to bind to only a single MessageContext, in which
case there are better ways to do it (i.e. provide an Options-style
interface that MC implements, but don't have a separate object), OR the
Options object should enable reuse of the same information across
multiple invocations, in which case it should have a separate property
store from the MessageContext to avoid the problems I previously
discussed. (Note that this technique involves no extra copies either -
the Options object simply gets searched after the MC's normal bag for
properties)
I've already implemented the latter, in fact - it was an easy bit of
work, and I just ran a successful build with the changes. So let me
toss the question back the other way... do you see anything WRONG with
having the MC and the Options object maintain separate (but related)
property stores?
Thanks,
--Glen
P.S. Regardless, I think we need to review the documentation...
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
