On Fri, 2007-01-05 at 11:01 -0800, Bill Nagy wrote:
> I'm not giving up, and I want to argue some more 8-].
:). Sorry for the delay .. was traveling again (yeah getting an early
start this year).
> >From a pure Axis context perspective, I agree (without having looked
> through the code in detail)
I'm not giving up, and I want to argue some more 8-].
>From a pure Axis context perspective, I agree (without having looked
through the code in detail) that your assertion about there not being
any private state is correct. From the perspective of the state as a
whole, I don't agree -- in our use
On Tue, 2007-01-02 at 15:28 -0800, Bill Nagy wrote:
> OK, here's my $0.02:
>
> (1)I would argue that reliable delivery of messages is an integral part
> of a web services stack and therefore deserves special treatment in the
> core where necessary so long as it does not adversely affect processing
On Wed, 2007-01-03 at 12:47 -0600, R J Scheuerle Jr wrote:
> Ann's code is not fundamentally changing the MessageContext. The new
> code may, over time, enhance the organization of the MessageContext
> graph. I am in favor of adding this patch for the sake of iterative
> development.
Fine. I just
Ann's code is not fundamentally changing the MessageContext. The new code
may, over time, enhance the organization of the MessageContext graph. I
am in favor of adding this patch for the sake of iterative development.
I am concerned that the arguments for/against are unduly based on company
OK, here's my $0.02:
(1)I would argue that reliable delivery of messages is an integral part
of a web services stack and therefore deserves special treatment in the
core where necessary so long as it does not adversely affect processing
when the reliability is achieved through other means (such as
There is a difference in saving the message versus saving the message
context.
Saving just the message text means that the message processing needs to be
redone from the beginning. There is no runtime state associated with the
message. There are no properties associated with the message. There i
Sanjiva,
My apologies for the extra long note. I am trying to address a number of
points.
On Thu, 12-21-2006, Sanjiva Weerawarana wrote:
> As far as I can see none of this data is private to a message context;
> so the answer to the question I asked earlier appears to be that this
> code can perf
On Thu, 2006-12-21 at 11:14 -0600, Ann Robinson wrote:
> I have submitted an updated patch for the message context save/restore
> proposal (under JIRA axis2-1567). Now, when a message context is
> restored, it looks for existing ServiceContext and ServiceGroupContext
> objects to use in its object
I have submitted an updated patch for the message context save/restore
proposal (under JIRA axis2-1567). Now, when a message context is restored,
it looks for existing ServiceContext and ServiceGroupContext objects to use
in its object hierarchy. This means that a restored object graph for a
Me
I have no objection to this proposed approach, but would like to hear
back from Ann on my last proposal on this thread- keep this code out of
the core if it doesn't depend on any private state in MC. I can't see
what that would be but am waiting to hear what private state is
interesting to save/re
David I appologize for the comment. Perhapse I took things a little too
much.
Rajith
On 12/19/06, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote:
On Mon, 2006-12-18 at 11:54 -0500, Rajith Attapattu wrote:
> c) Sorry for being blunt, but I honestly think, that this proposal is
> being pushed so
On Mon, 2006-12-18 at 16:05 +, Matthew Lovett wrote:
> I don't think that we can implement this in the Sandesha layer. There is
> too much private state inside the Axis objects that needs to be handled,
> and simply making all the objects have no-arg constructors & get/set for
> everything w
On Mon, 2006-12-18 at 11:54 -0500, Rajith Attapattu wrote:
> c) Sorry for being blunt, but I honestly think, that this proposal is
> being pushed so hard bcos it works with some IBM internal product.
There's nothing wrong with that- we should put in all the hooks needed
for anyone's products to wo
Ann,
Let's figure out a way to get out of this loop. No, i don't think
that we should add code just because it does not break any existing
things...
How about we start a branch for this work? I'd personally be satisfied
about moving to trunk when i see a test case in this branch that
illustrate
c) Sorry for being blunt, but I honestly think, that this proposal is
being pushed so hard bcos it works with some IBM internal product.
You're right it works with an IBM project (FWIW it also works with
Sandesha2) which is why I know it works and why I believe it's very
unlikely to break pure A
Just for the record I fully believe it works right now, I just haven't
dug into int in its entirety to understand it all.
David
On 18/12/06, Chamikara Jayalath <[EMAIL PROTECTED]> wrote:
Hi David, Sanjiva, All,
On 12/18/06, David Illsley <[EMAIL PROTECTED]> wrote:
> On 17/12/06, Sanjiva Weera
Hi David, Sanjiva, All,
On 12/18/06, David Illsley <[EMAIL PROTECTED]> wrote:
On 17/12/06, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote:
> On Tue, 2006-12-12 at 14:04 -0600, Ann Robinson wrote:
> > This proposal has been available for review and comment since
> > 2006-10-31.
> > I know the shu
Ann, David & Sanjiva,
I kept quiet all this time bcos, I was the only person who voiced my concern
about this issue a while back.
I will breifly outline my concerns for the benifit of thers (Ann has already
responded to my comments. Whether I agree with them or not is a different
thing)
a) IMHO
Hi Sanjiva,
Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote on 18/12/2006 14:49:15:
>
> OK how about this- Ann, since you just want to use this feature for your
> own persistence model for Sandesha and nothing else, then you don't need
> to put this code in the core at all: just write the same wri
On 18/12/06, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote:
On Mon, 2006-12-18 at 09:23 +, David Illsley wrote:
> >
> > I agree the proposal has been around for a long time but I've pointed
> > out that its flawed and you're saying "its not flawed for the way I want
> > to use it". But if any
On Mon, 2006-12-18 at 09:23 +, David Illsley wrote:
> >
> > I agree the proposal has been around for a long time but I've pointed
> > out that its flawed and you're saying "its not flawed for the way I want
> > to use it". But if anyone else does mc.serialize() and tries to bring it
> > back up
On 17/12/06, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote:
On Tue, 2006-12-12 at 14:04 -0600, Ann Robinson wrote:
> This proposal has been available for review and comment since
> 2006-10-31.
> I know the shutdown for Axis2 1.1 release took a lot of attention away
> from
> other items such as th
On 12/18/06, Ann Robinson <[EMAIL PROTECTED]> wrote:
Sanjiva,
Thanks for the response.
First of all, I have finished the implementation for your concern about
the ServiceContext properties and I am running through tests before
submitting an updated patch. With this updated patch, when the messa
Re: [AXIS2] Proposal for saving the
message c
On Tue, 2006-12-12 at 14:04 -0600, Ann Robinson wrote:
> This proposal has been available for review and comment since
> 2006-10-31.
> I know the shutdown for Axis2 1.1 release took a lot of attention away
> from
> other items such as this. However, the prototype for this proposal has
> been tested
>>On Fri, 2006-12-01 at 13:56 -0600, Ann Robinson wrote:
>>> Hi, Sanjiva,
>>> The proposal could be committed with little risk to the rest of Axis2.
>>> The save/restore of a message context is not an automatic action and
>>> so it would not affect current message handling.
>>
>>Yes but the code th
>On Fri, 2006-12-01 at 13:56 -0600, Ann Robinson wrote:
>> Hi, Sanjiva,
>> The proposal could be committed with little risk to the rest of Axis2.
>> The save/restore of a message context is not an automatic action and
>> so it would not affect current message handling.
>
>Yes but the code that's co
On Fri, 2006-12-01 at 13:56 -0600, Ann Robinson wrote:
> Hi, Sanjiva,
> The proposal could be committed with little risk to the rest of Axis2.
> The save/restore of a message context is not an automatic action and
> so it would not affect current message handling.
Yes but the code that's committed
On Thu, 2006-11-30 at 10:34 -0600, Ann Robinson wrote:
> You have a good point. In particular, I think this would apply to
> properties that are set on the ServiceContext. I think that figuring
> out how to reconcile a restored ServiceContext with an existing
> ServiceContext would be worthwhile
On Fri, 2006-12-01 at 10:34 +, Matthew Lovett wrote:
> Well, yes, but the current Sandesha approach has it's own issues too. I
> think that this proposal gives us an alternative, and we should get it
> into axis2 so that we can see what it enables in Sandesha. There is no
> problem with havi
On Thu, 2006-11-30 at 10:34 -0600, Ann Robinson wrote:
> You have a good point. In particular, I think this would apply to
> properties that are set on the ServiceContext. I think that figuring
> out how to reconcile a restored ServiceContext with an existing
> ServiceContext would be worthwhile t
Hi Matt,
On 12/1/06, Matthew Lovett <[EMAIL PROTECTED]> wrote:
Hi all,
Just a quick response to Chamikara's comments:
"Chamikara Jayalath" <[EMAIL PROTECTED]> wrote on 01/12/2006 00:45:00:
>
> I guess this applies not only to ServiceContexts but all the
> contexts that get serialized. When t
Hi all,
Just a quick response to Chamikara's comments:
"Chamikara Jayalath" <[EMAIL PROTECTED]> wrote on 01/12/2006 00:45:00:
>
> I guess this applies not only to ServiceContexts but all the
> contexts that get serialized. When two messages that share some top
> level contexts get serialized,
Hi Ann,
On 11/30/06, Ann Robinson <[EMAIL PROTECTED]> wrote:
Hi, Sanjiva,
Thanks for the comments. I have tagged your comments with
text to keep the indentation from getting too deep and
put my responses below your comments with the tags text.
Ann
>
> The save/restore of a MessageContext o
Hi, Sanjiva,
Thanks for the comments. I have tagged your comments with
text to keep the indentation from getting too deep and
put my responses below your comments with the tags text.
Ann
>
> The save/restore of a MessageContext object hierarchy attempts to
> reduce the duplication of parent-chi
Hi Ann,
>
> The save/restore of a MessageContext object hierarchy attempts to
> reduce the duplication of parent-child objects in that MessageContext
> object graph. The re-established MessageContext object graph keeps
> the *Context objects to a single set and gets the Axis* objects
> through t
Chamikara,
Thanks for your questions. My responses are below and are delimited with
text.
1. Serialization of parent contexts
Does the serialization of parents repeat for every message context or do
they get shared. If they do not I guess we hv to find out a way to share
them. Otherwise it will
10:30
PMSubject
Re: [AXIS2] Proposal for saving the
message context
Please resp
Hi Ann,
Thanks for comming up with this proposal. Quite a useful subject indeed.
I went through it and felt unclear about several areas. Here they are.
1. Serialization of parent contexts
Does the serialization of parents repeat for every message context or do
they get shared. If they do not I
I read thru the Wiki page but am a bit unclear on what is proposed. Are
you proposing that:
- All the context classes implement externalizable
- add a method configContext.activate(MessageContext)
Does the externalization involve storing names of the Axis* objects so
that those links can be re-es
Sorry for the delay Ann- I'll go thru this tomorrow and give feedback.
Thanks,
Sanjiva.
On Mon, 2006-11-27 at 10:47 -0600, Ann Robinson wrote:
> I have a proposal for saving the AXIS2 message context based on some
> of the discussion that occurred earlier this year. I have put a
> description o
I believe Ann has addressed all outstanding concerns with this issue. This
is excellent work and she has provided a very informative wiki page.
If there is no further discussion on this issue, I vote to commit Ann's
patch.
Rich Scheuerle
IBM Web Services
Apache Axis2 ([EMAIL PROTECTED])
512
Hi all,
I support this proposal. It gives us a way to simplify the outbound
Sandesha processing (no more need to force a dummy transport into the
outbound processing chain), helps integrate cleanly with security (no more
need to special-case security as a 'retransmittable phase'), and helps
en
I have a proposal for saving the AXIS2 message context based on some of the
discussion that occurred earlier this year. I have put a description of the
proposal on the Apache wiki at
http://wiki.apache.org/ws/FrontPage/Axis2/MessageContextSaveRestore
and I have submitted a patch for review in t
I have a proposal for saving the AXIS2 message context based on some of the
discussion that occurred earlier this year. I have put a description of the
proposal on the Apache wiki at
http://wiki.apache.org/ws/FrontPage/Axis2/MessageContextSaveRestore
and I have submitted a patch for review in t
I have a proposal for saving the AXIS2 message context based on some of the discussion that occurred earlier this year. I have put a description of the proposal on the Apache wiki at
http://wiki.apache.org/ws/FrontPage/Axis2/MessageContextSaveRestore
and I have submitted a patch for review in t
47 matches
Mail list logo
