You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fx-dev@ws.apache.org by Chamikara Jayalath <ch...@gmail.com> on 2006/11/29 05:47:22 UTC
Re: [AXIS2] Proposal for saving the message context
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 guess we hv to find out a way to share
them. Otherwise it will be a big waste of the storage.
2. ConfigurationContext
I'm not sure on how the information in the ConfigurationContext will be
serialized. You haven't mentioned in the list of contexts that get saved
with the MessageContext. But this may also contain useful runtime data which
may be needed by the entity that uses the MessageContext.
3. What actually happens in the 'msgContext2.activate(configurationContext)'
method.
4. As a whole your aproach is on making MessageContext implement
Externalizable right ?
5. How will this map to a environment where somebody wants to save the MC in
a database. For example Sandesha2 has a StorageManager inferace which could
be implemented by different storage mechanisms. How will you support such a
scenario with this.
Chamikara
p.s. (forwarding to sandesha-dev as well)
On 11/27/06, Ann Robinson <ro...@us.ibm.com> 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 of
> the proposal on the Apache wiki at
> *
> **http://wiki.apache.org/ws/FrontPage/Axis2/MessageContextSaveRestore *<http://wiki.apache.org/ws/FrontPage/Axis2/MessageContextSaveRestore>
>
> and I have submitted a patch for review in the JIRA issue AXIS2-1567.
>
> I would appreciate any comments on this proposal since it is particularly
> useful for a WS-RM implementation.
>
> Ann
>
> WebSphere Development, Web Services Engine
>
> IBM
> 11501 Burnet Rd IZip 9035G021
> Austin, TX 78758
> (512)838-9438 TL 678-9438
>
> Lotus Notes: Ann Robinson/Austin/IBM@IBMUS
> Internet: robinsona @ us.ibm.com
>
Re: [AXIS2] Proposal for saving the message context
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi Matt,
On 12/1/06, Matthew Lovett <ML...@uk.ibm.com> wrote:
>
> Hi all,
>
> Just a quick response to Chamikara's comments:
>
> "Chamikara Jayalath" <ch...@gmail.com> 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, two seperate instances of the same
> > top level context will be serialized. These two will be in two
> > different stages. Now the problem is how to reconstruct the system.
> > What top level context should we choose.
> >
> > This reconstruction problem was one reason for the Sandesha2 to go
> > for a model where the MessageContext get saved only after it goes
> > through the full Handler chain.
> >
>
> 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 having 2 in-memory storage managers for a while... one that
> forces in the dummy transport and runs the message through
> 'retransmittable phases', and one that calls the serialise code.
>
> All we'd need to do is move some of the transport-changing logic from
> SandeshaUtil into something associated with the storage manager.
> StorageManager.getUtil().executeAndStore(), etc...
>
> We could also generalise the unit tests so that we try them with both
> storage managers. That's no bad thing... for a while I've wanted to be
> able to run the tests with security turned on, and the same general
> mechanism would be handy there too.
I think having two InMemory Storage Managers in the same system will make it
unnecessarily complex. All we have to do is picking up a good solution and
going for it. And I dont agree on haking the StorageManager interface to
fascilitate that.
What we should do is trying to figure out a way to reconstruct the system
correctly. That aproach should not be wasting the storage unnecessarily and
should not be putting the system into any inconsistent states. If we can
come up with a solution to this problem I am ok with going with Anns
approach. But I dont think we should change the current working code,
thinking of a solution that will be found later.
Chamikara
---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
Re: [AXIS2] Proposal for saving the message context
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi Matt,
On 12/1/06, Matthew Lovett <ML...@uk.ibm.com> wrote:
>
> Hi all,
>
> Just a quick response to Chamikara's comments:
>
> "Chamikara Jayalath" <ch...@gmail.com> 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, two seperate instances of the same
> > top level context will be serialized. These two will be in two
> > different stages. Now the problem is how to reconstruct the system.
> > What top level context should we choose.
> >
> > This reconstruction problem was one reason for the Sandesha2 to go
> > for a model where the MessageContext get saved only after it goes
> > through the full Handler chain.
> >
>
> 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 having 2 in-memory storage managers for a while... one that
> forces in the dummy transport and runs the message through
> 'retransmittable phases', and one that calls the serialise code.
>
> All we'd need to do is move some of the transport-changing logic from
> SandeshaUtil into something associated with the storage manager.
> StorageManager.getUtil().executeAndStore(), etc...
>
> We could also generalise the unit tests so that we try them with both
> storage managers. That's no bad thing... for a while I've wanted to be
> able to run the tests with security turned on, and the same general
> mechanism would be handy there too.
I think having two InMemory Storage Managers in the same system will make it
unnecessarily complex. All we have to do is picking up a good solution and
going for it. And I dont agree on haking the StorageManager interface to
fascilitate that.
What we should do is trying to figure out a way to reconstruct the system
correctly. That aproach should not be wasting the storage unnecessarily and
should not be putting the system into any inconsistent states. If we can
come up with a solution to this problem I am ok with going with Anns
approach. But I dont think we should change the current working code,
thinking of a solution that will be found later.
Chamikara
---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
Re: [AXIS2] Proposal for saving the message context
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi Matt,
On 12/1/06, Matthew Lovett <ML...@uk.ibm.com> wrote:
>
> Hi all,
>
> Just a quick response to Chamikara's comments:
>
> "Chamikara Jayalath" <ch...@gmail.com> 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, two seperate instances of the same
> > top level context will be serialized. These two will be in two
> > different stages. Now the problem is how to reconstruct the system.
> > What top level context should we choose.
> >
> > This reconstruction problem was one reason for the Sandesha2 to go
> > for a model where the MessageContext get saved only after it goes
> > through the full Handler chain.
> >
>
> 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 having 2 in-memory storage managers for a while... one that
> forces in the dummy transport and runs the message through
> 'retransmittable phases', and one that calls the serialise code.
>
> All we'd need to do is move some of the transport-changing logic from
> SandeshaUtil into something associated with the storage manager.
> StorageManager.getUtil().executeAndStore(), etc...
>
> We could also generalise the unit tests so that we try them with both
> storage managers. That's no bad thing... for a while I've wanted to be
> able to run the tests with security turned on, and the same general
> mechanism would be handy there too.
I think having two InMemory Storage Managers in the same system will make it
unnecessarily complex. All we have to do is picking up a good solution and
going for it. And I dont agree on haking the StorageManager interface to
fascilitate that.
What we should do is trying to figure out a way to reconstruct the system
correctly. That aproach should not be wasting the storage unnecessarily and
should not be putting the system into any inconsistent states. If we can
come up with a solution to this problem I am ok with going with Anns
approach. But I dont think we should change the current working code,
thinking of a solution that will be found later.
Chamikara
---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
Re: [AXIS2] Proposal for saving the message context
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Fri, 2006-12-01 at 10:34 +0000, 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 having 2 in-memory storage managers for a while... one that
> forces in the dummy transport and runs the message through
> 'retransmittable phases', and one that calls the serialise code.
>
> All we'd need to do is move some of the transport-changing logic from
> SandeshaUtil into something associated with the storage manager.
> StorageManager.getUtil().executeAndStore(), etc...
>
> We could also generalise the unit tests so that we try them with both
> storage managers. That's no bad thing... for a while I've wanted to be
> able to run the tests with security turned on, and the same general
> mechanism would be handy there too.
My concerns have nothing to do with Sandesha- the code that's proposed
for Axis2 doesn't work as advertised because it reconstructs the system
in an inconsistent state.
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [AXIS2] Proposal for saving the message context
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Fri, 2006-12-01 at 10:34 +0000, 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 having 2 in-memory storage managers for a while... one that
> forces in the dummy transport and runs the message through
> 'retransmittable phases', and one that calls the serialise code.
>
> All we'd need to do is move some of the transport-changing logic from
> SandeshaUtil into something associated with the storage manager.
> StorageManager.getUtil().executeAndStore(), etc...
>
> We could also generalise the unit tests so that we try them with both
> storage managers. That's no bad thing... for a while I've wanted to be
> able to run the tests with security turned on, and the same general
> mechanism would be handy there too.
My concerns have nothing to do with Sandesha- the code that's proposed
for Axis2 doesn't work as advertised because it reconstructs the system
in an inconsistent state.
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [AXIS2] Proposal for saving the message context
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Fri, 2006-12-01 at 10:34 +0000, 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 having 2 in-memory storage managers for a while... one that
> forces in the dummy transport and runs the message through
> 'retransmittable phases', and one that calls the serialise code.
>
> All we'd need to do is move some of the transport-changing logic from
> SandeshaUtil into something associated with the storage manager.
> StorageManager.getUtil().executeAndStore(), etc...
>
> We could also generalise the unit tests so that we try them with both
> storage managers. That's no bad thing... for a while I've wanted to be
> able to run the tests with security turned on, and the same general
> mechanism would be handy there too.
My concerns have nothing to do with Sandesha- the code that's proposed
for Axis2 doesn't work as advertised because it reconstructs the system
in an inconsistent state.
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [AXIS2] Proposal for saving the message context
Posted by Matthew Lovett <ML...@uk.ibm.com>.
Hi all,
Just a quick response to Chamikara's comments:
"Chamikara Jayalath" <ch...@gmail.com> 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, two seperate instances of the same
> top level context will be serialized. These two will be in two
> different stages. Now the problem is how to reconstruct the system.
> What top level context should we choose.
>
> This reconstruction problem was one reason for the Sandesha2 to go
> for a model where the MessageContext get saved only after it goes
> through the full Handler chain.
>
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 having 2 in-memory storage managers for a while... one that
forces in the dummy transport and runs the message through
'retransmittable phases', and one that calls the serialise code.
All we'd need to do is move some of the transport-changing logic from
SandeshaUtil into something associated with the storage manager.
StorageManager.getUtil().executeAndStore(), etc...
We could also generalise the unit tests so that we try them with both
storage managers. That's no bad thing... for a while I've wanted to be
able to run the tests with security turned on, and the same general
mechanism would be handy there too.
Thanks
Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [AXIS2] Proposal for saving the message context
Posted by Matthew Lovett <ML...@uk.ibm.com>.
Hi all,
Just a quick response to Chamikara's comments:
"Chamikara Jayalath" <ch...@gmail.com> 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, two seperate instances of the same
> top level context will be serialized. These two will be in two
> different stages. Now the problem is how to reconstruct the system.
> What top level context should we choose.
>
> This reconstruction problem was one reason for the Sandesha2 to go
> for a model where the MessageContext get saved only after it goes
> through the full Handler chain.
>
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 having 2 in-memory storage managers for a while... one that
forces in the dummy transport and runs the message through
'retransmittable phases', and one that calls the serialise code.
All we'd need to do is move some of the transport-changing logic from
SandeshaUtil into something associated with the storage manager.
StorageManager.getUtil().executeAndStore(), etc...
We could also generalise the unit tests so that we try them with both
storage managers. That's no bad thing... for a while I've wanted to be
able to run the tests with security turned on, and the same general
mechanism would be handy there too.
Thanks
Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [AXIS2] Proposal for saving the message context
Posted by Matthew Lovett <ML...@uk.ibm.com>.
Hi all,
Just a quick response to Chamikara's comments:
"Chamikara Jayalath" <ch...@gmail.com> 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, two seperate instances of the same
> top level context will be serialized. These two will be in two
> different stages. Now the problem is how to reconstruct the system.
> What top level context should we choose.
>
> This reconstruction problem was one reason for the Sandesha2 to go
> for a model where the MessageContext get saved only after it goes
> through the full Handler chain.
>
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 having 2 in-memory storage managers for a while... one that
forces in the dummy transport and runs the message through
'retransmittable phases', and one that calls the serialise code.
All we'd need to do is move some of the transport-changing logic from
SandeshaUtil into something associated with the storage manager.
StorageManager.getUtil().executeAndStore(), etc...
We could also generalise the unit tests so that we try them with both
storage managers. That's no bad thing... for a while I've wanted to be
able to run the tests with security turned on, and the same general
mechanism would be handy there too.
Thanks
Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [AXIS2] Proposal for saving the message context
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi Ann,
On 11/30/06, Ann Robinson <ro...@us.ibm.com> wrote:
>
> Hi, Sanjiva,
> Thanks for the comments. I have tagged your comments with
> <sanjiva>text</sanjiva> to keep the indentation from getting too deep and
> put my responses below your comments with the tags <amr2>text</amr2>.
> Ann
>
> > <amr>
> > 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 the ConfigurationContext object associated with the AxisEngine
> > where the MessageContext was restored. So, the *Context objects are
> > unique across restored MessageContexts but the Axis* objects are
> > easily shared/re-used across restored MessageContexts. A future
> > refinement for the save/restore of the MessageContext is to find a way
> > to share *Context objects across restored MessageContexts. This is
> > actually a fairly small set of objects and involves the
> > OperationContext, ServiceContext, and ServiceGroupContext objects.
> > </amr>
>
> <sanjiva>
> Hmm. I don't think your approach will work if there's any serializable
> state the user has put into say ServiceContext and if that state gets
> modified by handlers after message reincarnation. There will be two
> different service contexts around and the "shared" value will no longer
> be shared.
> </sanjiva>
>
> <amr2>
> 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 to add to the proposal.
> </amr2>
>
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, two seperate instances of the same top level context will be
serialized. These two will be in two different stages. Now the problem is
how to reconstruct the system. What top level context should we choose.
This reconstruction problem was one reason for the Sandesha2 to go for a
model where the MessageContext get saved only after it goes through the full
Handler chain.
Chamikara
Re: [AXIS2] Proposal for saving the message context
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi Ann,
On 11/30/06, Ann Robinson <ro...@us.ibm.com> wrote:
>
> Hi, Sanjiva,
> Thanks for the comments. I have tagged your comments with
> <sanjiva>text</sanjiva> to keep the indentation from getting too deep and
> put my responses below your comments with the tags <amr2>text</amr2>.
> Ann
>
> > <amr>
> > 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 the ConfigurationContext object associated with the AxisEngine
> > where the MessageContext was restored. So, the *Context objects are
> > unique across restored MessageContexts but the Axis* objects are
> > easily shared/re-used across restored MessageContexts. A future
> > refinement for the save/restore of the MessageContext is to find a way
> > to share *Context objects across restored MessageContexts. This is
> > actually a fairly small set of objects and involves the
> > OperationContext, ServiceContext, and ServiceGroupContext objects.
> > </amr>
>
> <sanjiva>
> Hmm. I don't think your approach will work if there's any serializable
> state the user has put into say ServiceContext and if that state gets
> modified by handlers after message reincarnation. There will be two
> different service contexts around and the "shared" value will no longer
> be shared.
> </sanjiva>
>
> <amr2>
> 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 to add to the proposal.
> </amr2>
>
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, two seperate instances of the same top level context will be
serialized. These two will be in two different stages. Now the problem is
how to reconstruct the system. What top level context should we choose.
This reconstruction problem was one reason for the Sandesha2 to go for a
model where the MessageContext get saved only after it goes through the full
Handler chain.
Chamikara
Re: [AXIS2] Proposal for saving the message context
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi Ann,
On 11/30/06, Ann Robinson <ro...@us.ibm.com> wrote:
>
> Hi, Sanjiva,
> Thanks for the comments. I have tagged your comments with
> <sanjiva>text</sanjiva> to keep the indentation from getting too deep and
> put my responses below your comments with the tags <amr2>text</amr2>.
> Ann
>
> > <amr>
> > 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 the ConfigurationContext object associated with the AxisEngine
> > where the MessageContext was restored. So, the *Context objects are
> > unique across restored MessageContexts but the Axis* objects are
> > easily shared/re-used across restored MessageContexts. A future
> > refinement for the save/restore of the MessageContext is to find a way
> > to share *Context objects across restored MessageContexts. This is
> > actually a fairly small set of objects and involves the
> > OperationContext, ServiceContext, and ServiceGroupContext objects.
> > </amr>
>
> <sanjiva>
> Hmm. I don't think your approach will work if there's any serializable
> state the user has put into say ServiceContext and if that state gets
> modified by handlers after message reincarnation. There will be two
> different service contexts around and the "shared" value will no longer
> be shared.
> </sanjiva>
>
> <amr2>
> 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 to add to the proposal.
> </amr2>
>
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, two seperate instances of the same top level context will be
serialized. These two will be in two different stages. Now the problem is
how to reconstruct the system. What top level context should we choose.
This reconstruction problem was one reason for the Sandesha2 to go for a
model where the MessageContext get saved only after it goes through the full
Handler chain.
Chamikara
Re: [AXIS2] Proposal for saving the message context
Posted by Ann Robinson <ro...@us.ibm.com>.
>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 will not work according to Axis2 works
>and anyone else using it will find that out the hard way.
>
>That's not an acceptable commit right?
>
>Sanjiva.
Sanjiva,
Committing the code as-is will not disrupt anyone else. The function has to
be explicitly called. I expect to provide an update
to address your concerns over the ServiceContext fairly soon, so I expect
that the
window in which someone could use it and hit that problem will be short.
In this
respect, this is no different from someone using Axis2 and encountering a
problem
and opening a JIRA issue.
If finding someone to do the commit is a problem I would suggest Bill Nagy,
who
already has some familiarity with the message context save/restore code.
Ann
Re: [AXIS2] Proposal for saving the message context
Posted by Chamikara Jayalath <ch...@gmail.com>.
On 12/18/06, Ann Robinson <ro...@us.ibm.com> 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 message
> context is restored, it will look for existing ServiceContext and
> ServiceGroupContext objects and use those existing objects instead of unique
> objects. This means that the restored object graph for the MessageContext is
> made up of mostly existing objects (of the primary objects, only the
> MessageContext and OperationContext will ultimately be unique).
>
What if there is a premature restored version of a ServiceContext and a
stored version with quite a lot of state. We will not be able to ever
retrieve the state saved in the SC since all restored MCs will be
pointing to the one in the memory.
This is the main concern I have with the proposal you have sent. Things
become much complex when it comes to rebuilding of the context hierarchy.
Ignoring all other stored versions does not seem to be the right solution
here.
Chamikara
Re: [AXIS2] Proposal for saving the message context
Posted by Chamikara Jayalath <ch...@gmail.com>.
On 12/18/06, Ann Robinson <ro...@us.ibm.com> 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 message
> context is restored, it will look for existing ServiceContext and
> ServiceGroupContext objects and use those existing objects instead of unique
> objects. This means that the restored object graph for the MessageContext is
> made up of mostly existing objects (of the primary objects, only the
> MessageContext and OperationContext will ultimately be unique).
>
What if there is a premature restored version of a ServiceContext and a
stored version with quite a lot of state. We will not be able to ever
retrieve the state saved in the SC since all restored MCs will be
pointing to the one in the memory.
This is the main concern I have with the proposal you have sent. Things
become much complex when it comes to rebuilding of the context hierarchy.
Ignoring all other stored versions does not seem to be the right solution
here.
Chamikara
Re: [AXIS2] Proposal for saving the message context
Posted by Chamikara Jayalath <ch...@gmail.com>.
On 12/18/06, Ann Robinson <ro...@us.ibm.com> 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 message
> context is restored, it will look for existing ServiceContext and
> ServiceGroupContext objects and use those existing objects instead of unique
> objects. This means that the restored object graph for the MessageContext is
> made up of mostly existing objects (of the primary objects, only the
> MessageContext and OperationContext will ultimately be unique).
>
What if there is a premature restored version of a ServiceContext and a
stored version with quite a lot of state. We will not be able to ever
retrieve the state saved in the SC since all restored MCs will be
pointing to the one in the memory.
This is the main concern I have with the proposal you have sent. Things
become much complex when it comes to rebuilding of the context hierarchy.
Ignoring all other stored versions does not seem to be the right solution
here.
Chamikara
Re: [AXIS2] Proposal for saving the message context
Posted by David Illsley <da...@gmail.com>.
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 <ch...@gmail.com> wrote:
> Hi David, Sanjiva, All,
>
>
> On 12/18/06, David Illsley <da...@gmail.com> wrote:
> > On 17/12/06, Sanjiva Weerawarana <sa...@opensource.lk> 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 this. However, the prototype for this proposal has
> > > > been tested and
> > > > used internally so the prototype has reached a level of stability. I
> > > > think the risk of
> > > > introducing problems to the mainstream message processing is very
> > > > minimal.
> > >
> > > Yes, except it doesn't work as advertised in Axis2 core. It works for
> > > you for RM because you're not expecting the rest of the context
> > > hierarchy to come back the way it was when you deserialize.
> > >
> > > 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 it won't work.
> >
> > I don't buy this argument at all. Anyone who serializes a
> > MessageContext and expects a fully restored system just by
> > deserialising it again is IMO living in cloud cuckoo land. That's not
> > to say someone might not, but that there are any number of bits of
> > Axis2 that it isn't at all obvious how it works and some additional
> > investigation, doc reading and questions is required. I don't think
> > the limitations outlined by Ann are in any way an egregious addition
> > to those areas, and in addition they're well documented.
> >
> > I see this very much in the same scope as the clustering proposal -
> > i.e additional function that is:
> > 1. Complicated
> > 2. Not critical for every Axis2 user
> > 3. Not possible to fully isolate from axis2-kernel
> > 4. Potentially confusing for basic users
> > I certainly don't believe that the clustering proposal had all the
> > answers or gave a view of an implementation that I want in Axis2.
> > However, I think we went the right way in accepting the clustering
> > proposal despite these problems as we can simplify, hide and factor
> > out over time.
>
>
> Please feel free to send all your concerns regarding this proposal.
> Actually we really need comments from people with some experience since many
> of us are not experts in the area.
>
>
>
> > I believe the same holds for Message Context serialisation. I don't
> > fully understand all of it right now but I can see the benefit. Lets
> > work with it on the trunk and over time we can improve our
> > understanding and most likely some of the code (no offence intended
> > Ann!)
>
>
> Why not ceate a branch for this proposal and commit it there. It will be
> possible to merge things to the trunk once we get these issues solved. I
> dont agree with committing something that 'might work' into the trunk.
>
> Chamikara
>
>
>
>
> >
> > David
> >
> > P.S. I'm actually hopeful that the 2 pieces of work are complimentary
> > and that by adding both to head and working on them there we'll end up
> > with a much better kernel.
> >
> > > > I would really like to get this proposal at a point where it could be
> > > > included
> > > > in the Axis2 1.2 release. I am currently working on a solution for the
> > > > point
> > > > you made regarding the ServiceContext and I will provide an updated
> > > > patch.
> > >
> > > Looking forward to it.
> > >
> > > > What are the concerns/issues that are blocking the acceptance of
> > > > this proposal?
> > >
> > > I'd like to see some others weigh in. Bill, what do you think? I'm sure
> > > you understand the point I'm making and I'd like to hear whether you
> > > think its not important. If there are others who feel that its ok to
> > > commit it then I'll lift my objection; so far its been a conversation
> > > between Ann and myself and that's not good!
> > >
> > > Glen/Eran/Deepal/Dims/others?
> > >
> > > Sanjiva.
> > > --
> > > Sanjiva Weerawarana, Ph.D.
> > > Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> > > Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> > > Director; Open Source Initiative; http://www.opensource.org/
> > > Member; Apache Software Foundation; http://www.apache.org/
> > > Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> sandesha-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: sandesha-dev-help@ws.apache.org
> > >
> > >
> >
> >
> > --
> > David Illsley - IBM Web Services Development
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
>
>
--
David Illsley - IBM Web Services Development
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [AXIS2] Proposal for saving the message context
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi David, Sanjiva, All,
On 12/18/06, David Illsley <da...@gmail.com> wrote:
>
> On 17/12/06, Sanjiva Weerawarana <sa...@opensource.lk> 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 this. However, the prototype for this proposal has
> > > been tested and
> > > used internally so the prototype has reached a level of stability. I
> > > think the risk of
> > > introducing problems to the mainstream message processing is very
> > > minimal.
> >
> > Yes, except it doesn't work as advertised in Axis2 core. It works for
> > you for RM because you're not expecting the rest of the context
> > hierarchy to come back the way it was when you deserialize.
> >
> > 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 it won't work.
>
> I don't buy this argument at all. Anyone who serializes a
> MessageContext and expects a fully restored system just by
> deserialising it again is IMO living in cloud cuckoo land. That's not
> to say someone might not, but that there are any number of bits of
> Axis2 that it isn't at all obvious how it works and some additional
> investigation, doc reading and questions is required. I don't think
> the limitations outlined by Ann are in any way an egregious addition
> to those areas, and in addition they're well documented.
>
> I see this very much in the same scope as the clustering proposal -
> i.e additional function that is:
> 1. Complicated
> 2. Not critical for every Axis2 user
> 3. Not possible to fully isolate from axis2-kernel
> 4. Potentially confusing for basic users
I certainly don't believe that the clustering proposal had all the
> answers or gave a view of an implementation that I want in Axis2.
> However, I think we went the right way in accepting the clustering
> proposal despite these problems as we can simplify, hide and factor
> out over time.
Please feel free to send all your concerns regarding this proposal.
Actually we really need comments from people with some experience since many
of us are not experts in the area.
> I believe the same holds for Message Context serialisation. I don't
> fully understand all of it right now but I can see the benefit. Lets
> work with it on the trunk and over time we can improve our
> understanding and most likely some of the code (no offence intended
> Ann!)
Why not ceate a branch for this proposal and commit it there. It will be
possible to merge things to the trunk once we get these issues solved. I
dont agree with committing something that 'might work' into the trunk.
Chamikara
David
>
> P.S. I'm actually hopeful that the 2 pieces of work are complimentary
> and that by adding both to head and working on them there we'll end up
> with a much better kernel.
>
> > > I would really like to get this proposal at a point where it could be
> > > included
> > > in the Axis2 1.2 release. I am currently working on a solution for the
> > > point
> > > you made regarding the ServiceContext and I will provide an updated
> > > patch.
> >
> > Looking forward to it.
> >
> > > What are the concerns/issues that are blocking the acceptance of
> > > this proposal?
> >
> > I'd like to see some others weigh in. Bill, what do you think? I'm sure
> > you understand the point I'm making and I'd like to hear whether you
> > think its not important. If there are others who feel that its ok to
> > commit it then I'll lift my objection; so far its been a conversation
> > between Ann and myself and that's not good!
> >
> > Glen/Eran/Deepal/Dims/others?
> >
> > Sanjiva.
> > --
> > Sanjiva Weerawarana, Ph.D.
> > Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> > Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> > Director; Open Source Initiative; http://www.opensource.org/
> > Member; Apache Software Foundation; http://www.apache.org/
> > Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: sandesha-dev-help@ws.apache.org
> >
> >
>
>
> --
> David Illsley - IBM Web Services Development
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
Re: [AXIS2] Proposal for saving the message context
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi David, Sanjiva, All,
On 12/18/06, David Illsley <da...@gmail.com> wrote:
>
> On 17/12/06, Sanjiva Weerawarana <sa...@opensource.lk> 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 this. However, the prototype for this proposal has
> > > been tested and
> > > used internally so the prototype has reached a level of stability. I
> > > think the risk of
> > > introducing problems to the mainstream message processing is very
> > > minimal.
> >
> > Yes, except it doesn't work as advertised in Axis2 core. It works for
> > you for RM because you're not expecting the rest of the context
> > hierarchy to come back the way it was when you deserialize.
> >
> > 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 it won't work.
>
> I don't buy this argument at all. Anyone who serializes a
> MessageContext and expects a fully restored system just by
> deserialising it again is IMO living in cloud cuckoo land. That's not
> to say someone might not, but that there are any number of bits of
> Axis2 that it isn't at all obvious how it works and some additional
> investigation, doc reading and questions is required. I don't think
> the limitations outlined by Ann are in any way an egregious addition
> to those areas, and in addition they're well documented.
>
> I see this very much in the same scope as the clustering proposal -
> i.e additional function that is:
> 1. Complicated
> 2. Not critical for every Axis2 user
> 3. Not possible to fully isolate from axis2-kernel
> 4. Potentially confusing for basic users
I certainly don't believe that the clustering proposal had all the
> answers or gave a view of an implementation that I want in Axis2.
> However, I think we went the right way in accepting the clustering
> proposal despite these problems as we can simplify, hide and factor
> out over time.
Please feel free to send all your concerns regarding this proposal.
Actually we really need comments from people with some experience since many
of us are not experts in the area.
> I believe the same holds for Message Context serialisation. I don't
> fully understand all of it right now but I can see the benefit. Lets
> work with it on the trunk and over time we can improve our
> understanding and most likely some of the code (no offence intended
> Ann!)
Why not ceate a branch for this proposal and commit it there. It will be
possible to merge things to the trunk once we get these issues solved. I
dont agree with committing something that 'might work' into the trunk.
Chamikara
David
>
> P.S. I'm actually hopeful that the 2 pieces of work are complimentary
> and that by adding both to head and working on them there we'll end up
> with a much better kernel.
>
> > > I would really like to get this proposal at a point where it could be
> > > included
> > > in the Axis2 1.2 release. I am currently working on a solution for the
> > > point
> > > you made regarding the ServiceContext and I will provide an updated
> > > patch.
> >
> > Looking forward to it.
> >
> > > What are the concerns/issues that are blocking the acceptance of
> > > this proposal?
> >
> > I'd like to see some others weigh in. Bill, what do you think? I'm sure
> > you understand the point I'm making and I'd like to hear whether you
> > think its not important. If there are others who feel that its ok to
> > commit it then I'll lift my objection; so far its been a conversation
> > between Ann and myself and that's not good!
> >
> > Glen/Eran/Deepal/Dims/others?
> >
> > Sanjiva.
> > --
> > Sanjiva Weerawarana, Ph.D.
> > Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> > Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> > Director; Open Source Initiative; http://www.opensource.org/
> > Member; Apache Software Foundation; http://www.apache.org/
> > Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: sandesha-dev-help@ws.apache.org
> >
> >
>
>
> --
> David Illsley - IBM Web Services Development
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
Re: [AXIS2] Proposal for saving the message context
Posted by Rajith Attapattu <ra...@gmail.com>.
David I appologize for the comment. Perhapse I took things a little too
much.
Rajith
On 12/19/06, Sanjiva Weerawarana <sa...@opensource.lk> 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 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 work well. The only concern I have is that we
> need to make sure the hooks we put in work as advertised.
>
> Sanjiva.
> --
> Sanjiva Weerawarana, Ph.D.
> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> Director; Open Source Initiative; http://www.opensource.org/
> Member; Apache Software Foundation; http://www.apache.org/
> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
Re: [AXIS2] Proposal for saving the message context
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
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 work well. The only concern I have is that we
need to make sure the hooks we put in work as advertised.
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [AXIS2] Proposal for saving the message context
Posted by David Illsley <da...@gmail.com>.
>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 Axis2.
I'm not philosphically attached to any particular way of implementing
this function, but I've seen it working so I thought I'd jump in and
comment when I thought the discussion seemed more
philosophical+process related that technical.
Apologies for any ill-will my comments have caused,
David
--
David Illsley - IBM Web Services Development
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [AXIS2] Proposal for saving the message context
Posted by Rajith Attapattu <ra...@gmail.com>.
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 if the context heirachy restoration is not brought back to the
original state then whats the point of serializing the context heirachy in
the first place.
b) As Ann mentioned before the idea or the value of the proposal "is to
restart a message in progress from where it was stopped w/o having to start
from the begning". IMHO this is not much of a value addition to axis2
compared to the complications in the code base required to achive this.
Here is my point. We are spending far more processing power to save the
message contexts anticipating a server crash, than to have the aborted
messages start from the beging if a server crash occurred.
If u pair it up with Sandesha2 we are garunteeing the excution of each
message, so we are not loosing any messages, but will restart processing
from the begining if a server crash occured.
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.
I actually don't care if this improves axis2 in some way or the other. I
think the complications introduced to the core far out weighs the benifits
provided by this implementation.
Regards,
Rajith
Btw, David, Can u please outline your concerns regarding clustering ? I may
have missed this.
Also I would like if u can explain the following comment a bit more.
>>I certainly don't believe that the clustering proposal had all the
>>answers or gave a view of an implementation that I want in Axis2.
On 12/18/06, Matthew Lovett <ML...@uk.ibm.com> wrote:
>
> Hi Sanjiva,
>
> Sanjiva Weerawarana <sa...@opensource.lk> 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 writeObject and
> > readObject methods in a utility class in Sandesha2 and call it yourself.
> > The only diff is where the code goes.
>
> 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 would be very ugly - and break encapsulation. That's why the
> classes themselves need to implement their own save/restore logic.
>
> > I'm surprised I'm the only one who cares about this to comment!
> >
>
> I do care about this stuff too, and I'd like to see it in Axis.
>
> Matt
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
Re: [AXIS2] Proposal for saving the message context
Posted by David Illsley <da...@gmail.com>.
On 18/12/06, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> On Mon, 2006-12-18 at 09:23 +0000, 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 it won't work.
> >
> > I don't buy this argument at all. Anyone who serializes a
> > MessageContext and expects a fully restored system just by
> > deserialising it again is IMO living in cloud cuckoo land.
>
> ?? If that's not the case then what is the point of message context
> serialization and deserialization?
The point (as I understand it) is to enable persistance for RM with a
clean architecture that composes well with other WS-* work. That's
entirely different than a generic statement that I should be able to
serialize an abritrary part of the system and recreate an entire
system from it with a single deserialize call.
>
> 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 writeObject and
> readObject methods in a utility class in Sandesha2 and call it yourself.
> The only diff is where the code goes.
>
> If that works then there's no problem at all.
>
> > That's not
> > to say someone might not, but that there are any number of bits of
> > Axis2 that it isn't at all obvious how it works and some additional
> > investigation, doc reading and questions is required. I don't think
> > the limitations outlined by Ann are in any way an egregious addition
> > to those areas, and in addition they're well documented.
>
> I agree its documented but if there's no need to do it I'm confused why
> there's insistence on making a core change for something that's focused
> on a specific usecase- do the code just for that case then.
>
> > I see this very much in the same scope as the clustering proposal -
> > i.e additional function that is:
> > 1. Complicated
> > 2. Not critical for every Axis2 user
> > 3. Not possible to fully isolate from axis2-kernel
> > 4. Potentially confusing for basic users
>
> Java object serialization is a fundamental thing in Java and many many
> people are aware of it and use it for various things. That's hardly
> comparable to someone messing with a clustering API.
>
OK, that's a fair point, maybe 4 isn't valid for comparison. Perhaps
theres something that could be done to make the default serialisation
less confusing like (off the top of my head) throwing an exception if
a flag isn't set on the specific MC.
> > I certainly don't believe that the clustering proposal had all the
> > answers or gave a view of an implementation that I want in Axis2.
>
> I don't recall seeing any issues raised by you ... did I miss it?
No, I didn't want to derail the proposal because of the few bits that
looked ugly because we can deal with that when it exists and we've had
a chance to test it all... I may be wrong and the proposal may be the
bext way to do it :-)
>
> > However, I think we went the right way in accepting the clustering
> > proposal despite these problems as we can simplify, hide and factor
> > out over time.
> >
> > I believe the same holds for Message Context serialisation. I don't
> > fully understand all of it right now but I can see the benefit. Lets
> > work with it on the trunk and over time we can improve our
> > understanding and most likely some of the code (no offence intended
> > Ann!)
>
> I have no objection to this approach in general and we've done that many
> times. Iterative development is of course the right way to do things.
>
> However I'd like to understand whether this issue can be dealt with
> locally for Sandesha only or not.
I think Bill talked about this a while ago... Bill?
David
>
> > P.S. I'm actually hopeful that the 2 pieces of work are complimentary
> > and that by adding both to head and working on them there we'll end up
> > with a much better kernel.
>
> Sorry I didn't grok which 2 pieces of work you're referring to? Are you
> talking about using MC serialization for clustering as well? That's a
> very good example of someone wanting to use the mc serialization stuff
> and it failing totally, even with the proposed solution Ann's now
> working on now.
>
> I'm surprised I'm the only one who cares about this to comment!
>
> Sanjiva.
> --
> Sanjiva Weerawarana, Ph.D.
> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> Director; Open Source Initiative; http://www.opensource.org/
> Member; Apache Software Foundation; http://www.apache.org/
> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
David Illsley - IBM Web Services Development
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [AXIS2] Proposal for saving the message context
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Mon, 2006-12-18 at 16:05 +0000, 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 would be very ugly - and break encapsulation. That's why the
> classes themselves need to implement their own save/restore logic.
Ann, can you point to some of the private state you need to
save/restore? Just thinking off the top of my head it seems to me all
you'd need to save/restore are public properties. What am I missing?
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [AXIS2] Proposal for saving the message context
Posted by Matthew Lovett <ML...@uk.ibm.com>.
Hi Sanjiva,
Sanjiva Weerawarana <sa...@opensource.lk> 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 writeObject and
> readObject methods in a utility class in Sandesha2 and call it yourself.
> The only diff is where the code goes.
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 would be very ugly - and break encapsulation. That's why the
classes themselves need to implement their own save/restore logic.
> I'm surprised I'm the only one who cares about this to comment!
>
I do care about this stuff too, and I'd like to see it in Axis.
Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [AXIS2] Proposal for saving the message context
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Mon, 2006-12-18 at 09:23 +0000, 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 it won't work.
>
> I don't buy this argument at all. Anyone who serializes a
> MessageContext and expects a fully restored system just by
> deserialising it again is IMO living in cloud cuckoo land.
?? If that's not the case then what is the point of message context
serialization and deserialization?
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 writeObject and
readObject methods in a utility class in Sandesha2 and call it yourself.
The only diff is where the code goes.
If that works then there's no problem at all.
> That's not
> to say someone might not, but that there are any number of bits of
> Axis2 that it isn't at all obvious how it works and some additional
> investigation, doc reading and questions is required. I don't think
> the limitations outlined by Ann are in any way an egregious addition
> to those areas, and in addition they're well documented.
I agree its documented but if there's no need to do it I'm confused why
there's insistence on making a core change for something that's focused
on a specific usecase- do the code just for that case then.
> I see this very much in the same scope as the clustering proposal -
> i.e additional function that is:
> 1. Complicated
> 2. Not critical for every Axis2 user
> 3. Not possible to fully isolate from axis2-kernel
> 4. Potentially confusing for basic users
Java object serialization is a fundamental thing in Java and many many
people are aware of it and use it for various things. That's hardly
comparable to someone messing with a clustering API.
> I certainly don't believe that the clustering proposal had all the
> answers or gave a view of an implementation that I want in Axis2.
I don't recall seeing any issues raised by you ... did I miss it?
> However, I think we went the right way in accepting the clustering
> proposal despite these problems as we can simplify, hide and factor
> out over time.
>
> I believe the same holds for Message Context serialisation. I don't
> fully understand all of it right now but I can see the benefit. Lets
> work with it on the trunk and over time we can improve our
> understanding and most likely some of the code (no offence intended
> Ann!)
I have no objection to this approach in general and we've done that many
times. Iterative development is of course the right way to do things.
However I'd like to understand whether this issue can be dealt with
locally for Sandesha only or not.
> P.S. I'm actually hopeful that the 2 pieces of work are complimentary
> and that by adding both to head and working on them there we'll end up
> with a much better kernel.
Sorry I didn't grok which 2 pieces of work you're referring to? Are you
talking about using MC serialization for clustering as well? That's a
very good example of someone wanting to use the mc serialization stuff
and it failing totally, even with the proposed solution Ann's now
working on now.
I'm surprised I'm the only one who cares about this to comment!
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [AXIS2] Proposal for saving the message context
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi David, Sanjiva, All,
On 12/18/06, David Illsley <da...@gmail.com> wrote:
>
> On 17/12/06, Sanjiva Weerawarana <sa...@opensource.lk> 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 this. However, the prototype for this proposal has
> > > been tested and
> > > used internally so the prototype has reached a level of stability. I
> > > think the risk of
> > > introducing problems to the mainstream message processing is very
> > > minimal.
> >
> > Yes, except it doesn't work as advertised in Axis2 core. It works for
> > you for RM because you're not expecting the rest of the context
> > hierarchy to come back the way it was when you deserialize.
> >
> > 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 it won't work.
>
> I don't buy this argument at all. Anyone who serializes a
> MessageContext and expects a fully restored system just by
> deserialising it again is IMO living in cloud cuckoo land. That's not
> to say someone might not, but that there are any number of bits of
> Axis2 that it isn't at all obvious how it works and some additional
> investigation, doc reading and questions is required. I don't think
> the limitations outlined by Ann are in any way an egregious addition
> to those areas, and in addition they're well documented.
>
> I see this very much in the same scope as the clustering proposal -
> i.e additional function that is:
> 1. Complicated
> 2. Not critical for every Axis2 user
> 3. Not possible to fully isolate from axis2-kernel
> 4. Potentially confusing for basic users
I certainly don't believe that the clustering proposal had all the
> answers or gave a view of an implementation that I want in Axis2.
> However, I think we went the right way in accepting the clustering
> proposal despite these problems as we can simplify, hide and factor
> out over time.
Please feel free to send all your concerns regarding this proposal.
Actually we really need comments from people with some experience since many
of us are not experts in the area.
> I believe the same holds for Message Context serialisation. I don't
> fully understand all of it right now but I can see the benefit. Lets
> work with it on the trunk and over time we can improve our
> understanding and most likely some of the code (no offence intended
> Ann!)
Why not ceate a branch for this proposal and commit it there. It will be
possible to merge things to the trunk once we get these issues solved. I
dont agree with committing something that 'might work' into the trunk.
Chamikara
David
>
> P.S. I'm actually hopeful that the 2 pieces of work are complimentary
> and that by adding both to head and working on them there we'll end up
> with a much better kernel.
>
> > > I would really like to get this proposal at a point where it could be
> > > included
> > > in the Axis2 1.2 release. I am currently working on a solution for the
> > > point
> > > you made regarding the ServiceContext and I will provide an updated
> > > patch.
> >
> > Looking forward to it.
> >
> > > What are the concerns/issues that are blocking the acceptance of
> > > this proposal?
> >
> > I'd like to see some others weigh in. Bill, what do you think? I'm sure
> > you understand the point I'm making and I'd like to hear whether you
> > think its not important. If there are others who feel that its ok to
> > commit it then I'll lift my objection; so far its been a conversation
> > between Ann and myself and that's not good!
> >
> > Glen/Eran/Deepal/Dims/others?
> >
> > Sanjiva.
> > --
> > Sanjiva Weerawarana, Ph.D.
> > Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> > Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> > Director; Open Source Initiative; http://www.opensource.org/
> > Member; Apache Software Foundation; http://www.apache.org/
> > Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: sandesha-dev-help@ws.apache.org
> >
> >
>
>
> --
> David Illsley - IBM Web Services Development
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
Re: [AXIS2] Proposal for saving the message context
Posted by David Illsley <da...@gmail.com>.
On 17/12/06, Sanjiva Weerawarana <sa...@opensource.lk> 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 this. However, the prototype for this proposal has
> > been tested and
> > used internally so the prototype has reached a level of stability. I
> > think the risk of
> > introducing problems to the mainstream message processing is very
> > minimal.
>
> Yes, except it doesn't work as advertised in Axis2 core. It works for
> you for RM because you're not expecting the rest of the context
> hierarchy to come back the way it was when you deserialize.
>
> 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 it won't work.
I don't buy this argument at all. Anyone who serializes a
MessageContext and expects a fully restored system just by
deserialising it again is IMO living in cloud cuckoo land. That's not
to say someone might not, but that there are any number of bits of
Axis2 that it isn't at all obvious how it works and some additional
investigation, doc reading and questions is required. I don't think
the limitations outlined by Ann are in any way an egregious addition
to those areas, and in addition they're well documented.
I see this very much in the same scope as the clustering proposal -
i.e additional function that is:
1. Complicated
2. Not critical for every Axis2 user
3. Not possible to fully isolate from axis2-kernel
4. Potentially confusing for basic users
I certainly don't believe that the clustering proposal had all the
answers or gave a view of an implementation that I want in Axis2.
However, I think we went the right way in accepting the clustering
proposal despite these problems as we can simplify, hide and factor
out over time.
I believe the same holds for Message Context serialisation. I don't
fully understand all of it right now but I can see the benefit. Lets
work with it on the trunk and over time we can improve our
understanding and most likely some of the code (no offence intended
Ann!)
David
P.S. I'm actually hopeful that the 2 pieces of work are complimentary
and that by adding both to head and working on them there we'll end up
with a much better kernel.
> > I would really like to get this proposal at a point where it could be
> > included
> > in the Axis2 1.2 release. I am currently working on a solution for the
> > point
> > you made regarding the ServiceContext and I will provide an updated
> > patch.
>
> Looking forward to it.
>
> > What are the concerns/issues that are blocking the acceptance of
> > this proposal?
>
> I'd like to see some others weigh in. Bill, what do you think? I'm sure
> you understand the point I'm making and I'd like to hear whether you
> think its not important. If there are others who feel that its ok to
> commit it then I'll lift my objection; so far its been a conversation
> between Ann and myself and that's not good!
>
> Glen/Eran/Deepal/Dims/others?
>
> Sanjiva.
> --
> Sanjiva Weerawarana, Ph.D.
> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> Director; Open Source Initiative; http://www.opensource.org/
> Member; Apache Software Foundation; http://www.apache.org/
> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
>
--
David Illsley - IBM Web Services Development
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [AXIS2] Proposal for saving the message context
Posted by Ann Robinson <ro...@us.ibm.com>.
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 message context is
restored, it will look for existing ServiceContext and ServiceGroupContext
objects and use those existing objects instead of unique objects. This
means that the restored object graph for the MessageContext is made up of
mostly existing objects (of the primary objects, only the MessageContext
and OperationContext will ultimately be unique). I expect to submit this
updated patch in a couple of days.
I would really like to see this proposal get committed when the updated
patch is available. The prototype for the message context save/restore has
been through a fair amount of testing and reached a level of stability, and
the risk to the rest of AXIS2 should be minimal. With the updated patch,
the message context save/restore proposal should be architecturally
complete, with maximum object re-use where possible. Also, getting the
commit done would allow me to verify the commit in the Axis2 source before
many folks take off for end-of-year holidays.
Ann
WebSphere Development, Web Services Engine
IBM
11501 Burnet Rd IZip 9035G021
Austin, TX 78758
(512)838-9438 TL 678-9438
Lotus Notes: Ann Robinson/Austin/IBM@IBMUS
Internet: robinsona @ us.ibm.com
Sanjiva
Weerawarana
<sanjiva@opensour To
ce.lk> axis-dev@ws.apache.org
cc
12/17/2006 11:53 sandesha-dev@ws.apache.org
AM Subject
Re: [AXIS2] Proposal for saving the
message context
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 and
> used internally so the prototype has reached a level of stability. I
> think the risk of
> introducing problems to the mainstream message processing is very
> minimal.
Yes, except it doesn't work as advertised in Axis2 core. It works for
you for RM because you're not expecting the rest of the context
hierarchy to come back the way it was when you deserialize.
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 it won't work.
> I would really like to get this proposal at a point where it could be
> included
> in the Axis2 1.2 release. I am currently working on a solution for the
> point
> you made regarding the ServiceContext and I will provide an updated
> patch.
Looking forward to it.
> What are the concerns/issues that are blocking the acceptance of
> this proposal?
I'd like to see some others weigh in. Bill, what do you think? I'm sure
you understand the point I'm making and I'd like to hear whether you
think its not important. If there are others who feel that its ok to
commit it then I'll lift my objection; so far its been a conversation
between Ann and myself and that's not good!
Glen/Eran/Deepal/Dims/others?
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [AXIS2] Proposal for saving the message context
Posted by Ann Robinson <ro...@us.ibm.com>.
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 message context is
restored, it will look for existing ServiceContext and ServiceGroupContext
objects and use those existing objects instead of unique objects. This
means that the restored object graph for the MessageContext is made up of
mostly existing objects (of the primary objects, only the MessageContext
and OperationContext will ultimately be unique). I expect to submit this
updated patch in a couple of days.
I would really like to see this proposal get committed when the updated
patch is available. The prototype for the message context save/restore has
been through a fair amount of testing and reached a level of stability, and
the risk to the rest of AXIS2 should be minimal. With the updated patch,
the message context save/restore proposal should be architecturally
complete, with maximum object re-use where possible. Also, getting the
commit done would allow me to verify the commit in the Axis2 source before
many folks take off for end-of-year holidays.
Ann
WebSphere Development, Web Services Engine
IBM
11501 Burnet Rd IZip 9035G021
Austin, TX 78758
(512)838-9438 TL 678-9438
Lotus Notes: Ann Robinson/Austin/IBM@IBMUS
Internet: robinsona @ us.ibm.com
Sanjiva
Weerawarana
<sanjiva@opensour To
ce.lk> axis-dev@ws.apache.org
cc
12/17/2006 11:53 sandesha-dev@ws.apache.org
AM Subject
Re: [AXIS2] Proposal for saving the
message context
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 and
> used internally so the prototype has reached a level of stability. I
> think the risk of
> introducing problems to the mainstream message processing is very
> minimal.
Yes, except it doesn't work as advertised in Axis2 core. It works for
you for RM because you're not expecting the rest of the context
hierarchy to come back the way it was when you deserialize.
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 it won't work.
> I would really like to get this proposal at a point where it could be
> included
> in the Axis2 1.2 release. I am currently working on a solution for the
> point
> you made regarding the ServiceContext and I will provide an updated
> patch.
Looking forward to it.
> What are the concerns/issues that are blocking the acceptance of
> this proposal?
I'd like to see some others weigh in. Bill, what do you think? I'm sure
you understand the point I'm making and I'd like to hear whether you
think its not important. If there are others who feel that its ok to
commit it then I'll lift my objection; so far its been a conversation
between Ann and myself and that's not good!
Glen/Eran/Deepal/Dims/others?
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [AXIS2] Proposal for saving the message context
Posted by Ann Robinson <ro...@us.ibm.com>.
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 message context is
restored, it will look for existing ServiceContext and ServiceGroupContext
objects and use those existing objects instead of unique objects. This
means that the restored object graph for the MessageContext is made up of
mostly existing objects (of the primary objects, only the MessageContext
and OperationContext will ultimately be unique). I expect to submit this
updated patch in a couple of days.
I would really like to see this proposal get committed when the updated
patch is available. The prototype for the message context save/restore has
been through a fair amount of testing and reached a level of stability, and
the risk to the rest of AXIS2 should be minimal. With the updated patch,
the message context save/restore proposal should be architecturally
complete, with maximum object re-use where possible. Also, getting the
commit done would allow me to verify the commit in the Axis2 source before
many folks take off for end-of-year holidays.
Ann
WebSphere Development, Web Services Engine
IBM
11501 Burnet Rd IZip 9035G021
Austin, TX 78758
(512)838-9438 TL 678-9438
Lotus Notes: Ann Robinson/Austin/IBM@IBMUS
Internet: robinsona @ us.ibm.com
Sanjiva
Weerawarana
<sanjiva@opensour To
ce.lk> axis-dev@ws.apache.org
cc
12/17/2006 11:53 sandesha-dev@ws.apache.org
AM Subject
Re: [AXIS2] Proposal for saving the
message context
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 and
> used internally so the prototype has reached a level of stability. I
> think the risk of
> introducing problems to the mainstream message processing is very
> minimal.
Yes, except it doesn't work as advertised in Axis2 core. It works for
you for RM because you're not expecting the rest of the context
hierarchy to come back the way it was when you deserialize.
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 it won't work.
> I would really like to get this proposal at a point where it could be
> included
> in the Axis2 1.2 release. I am currently working on a solution for the
> point
> you made regarding the ServiceContext and I will provide an updated
> patch.
Looking forward to it.
> What are the concerns/issues that are blocking the acceptance of
> this proposal?
I'd like to see some others weigh in. Bill, what do you think? I'm sure
you understand the point I'm making and I'd like to hear whether you
think its not important. If there are others who feel that its ok to
commit it then I'll lift my objection; so far its been a conversation
between Ann and myself and that's not good!
Glen/Eran/Deepal/Dims/others?
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [AXIS2] Proposal for saving the message context
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
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 and
> used internally so the prototype has reached a level of stability. I
> think the risk of
> introducing problems to the mainstream message processing is very
> minimal.
Yes, except it doesn't work as advertised in Axis2 core. It works for
you for RM because you're not expecting the rest of the context
hierarchy to come back the way it was when you deserialize.
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 it won't work.
> I would really like to get this proposal at a point where it could be
> included
> in the Axis2 1.2 release. I am currently working on a solution for the
> point
> you made regarding the ServiceContext and I will provide an updated
> patch.
Looking forward to it.
> What are the concerns/issues that are blocking the acceptance of
> this proposal?
I'd like to see some others weigh in. Bill, what do you think? I'm sure
you understand the point I'm making and I'd like to hear whether you
think its not important. If there are others who feel that its ok to
commit it then I'll lift my objection; so far its been a conversation
between Ann and myself and that's not good!
Glen/Eran/Deepal/Dims/others?
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [AXIS2] Proposal for saving the message context
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
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 and
> used internally so the prototype has reached a level of stability. I
> think the risk of
> introducing problems to the mainstream message processing is very
> minimal.
Yes, except it doesn't work as advertised in Axis2 core. It works for
you for RM because you're not expecting the rest of the context
hierarchy to come back the way it was when you deserialize.
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 it won't work.
> I would really like to get this proposal at a point where it could be
> included
> in the Axis2 1.2 release. I am currently working on a solution for the
> point
> you made regarding the ServiceContext and I will provide an updated
> patch.
Looking forward to it.
> What are the concerns/issues that are blocking the acceptance of
> this proposal?
I'd like to see some others weigh in. Bill, what do you think? I'm sure
you understand the point I'm making and I'd like to hear whether you
think its not important. If there are others who feel that its ok to
commit it then I'll lift my objection; so far its been a conversation
between Ann and myself and that's not good!
Glen/Eran/Deepal/Dims/others?
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [AXIS2] Proposal for saving the message context
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
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 and
> used internally so the prototype has reached a level of stability. I
> think the risk of
> introducing problems to the mainstream message processing is very
> minimal.
Yes, except it doesn't work as advertised in Axis2 core. It works for
you for RM because you're not expecting the rest of the context
hierarchy to come back the way it was when you deserialize.
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 it won't work.
> I would really like to get this proposal at a point where it could be
> included
> in the Axis2 1.2 release. I am currently working on a solution for the
> point
> you made regarding the ServiceContext and I will provide an updated
> patch.
Looking forward to it.
> What are the concerns/issues that are blocking the acceptance of
> this proposal?
I'd like to see some others weigh in. Bill, what do you think? I'm sure
you understand the point I'm making and I'd like to hear whether you
think its not important. If there are others who feel that its ok to
commit it then I'll lift my objection; so far its been a conversation
between Ann and myself and that's not good!
Glen/Eran/Deepal/Dims/others?
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [AXIS2] Proposal for saving the message context
Posted by Ann Robinson <ro...@us.ibm.com>.
>>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 will not work according to Axis2 works
>>and anyone else using it will find that out the hard way.
>>
>>That's not an acceptable commit right?
>>
>>Sanjiva.
>
>On Mon, 2006-12-11, Ann Robinson wrote:
> Sanjiva,
>
> Committing the code as-is will not disrupt anyone else. The function has
to
> be explicitly called. I expect to provide an update
> to address your concerns over the ServiceContext fairly soon, so I expect
that the
> window in which someone could use it and hit that problem will be short.
In this
> respect, this is no different from someone using Axis2 and encountering a
problem
> and opening a JIRA issue.
>
> If finding someone to do the commit is a problem I would suggest Bill
Nagy, who
> already has some familiarity with the message context save/restore code.
>
> Ann
>
Sanjiva,
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 and
used internally so the prototype has reached a level of stability. I think
the risk of
introducing problems to the mainstream message processing is very minimal.
This proposal does not change Axis2 architecture but instead deals with the
existing structure of the Axis2 message context object graph and message
processing.
I would really like to get this proposal at a point where it could be
included
in the Axis2 1.2 release. I am currently working on a solution for the
point
you made regarding the ServiceContext and I will provide an updated
patch.
What are the concerns/issues that are blocking the acceptance of
this proposal?
Ann
Re: [AXIS2] Proposal for saving the message context
Posted by Ann Robinson <ro...@us.ibm.com>.
>>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 will not work according to Axis2 works
>>and anyone else using it will find that out the hard way.
>>
>>That's not an acceptable commit right?
>>
>>Sanjiva.
>
>On Mon, 2006-12-11, Ann Robinson wrote:
> Sanjiva,
>
> Committing the code as-is will not disrupt anyone else. The function has
to
> be explicitly called. I expect to provide an update
> to address your concerns over the ServiceContext fairly soon, so I expect
that the
> window in which someone could use it and hit that problem will be short.
In this
> respect, this is no different from someone using Axis2 and encountering a
problem
> and opening a JIRA issue.
>
> If finding someone to do the commit is a problem I would suggest Bill
Nagy, who
> already has some familiarity with the message context save/restore code.
>
> Ann
>
Sanjiva,
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 and
used internally so the prototype has reached a level of stability. I think
the risk of
introducing problems to the mainstream message processing is very minimal.
This proposal does not change Axis2 architecture but instead deals with the
existing structure of the Axis2 message context object graph and message
processing.
I would really like to get this proposal at a point where it could be
included
in the Axis2 1.2 release. I am currently working on a solution for the
point
you made regarding the ServiceContext and I will provide an updated
patch.
What are the concerns/issues that are blocking the acceptance of
this proposal?
Ann
Re: [AXIS2] Proposal for saving the message context
Posted by Ann Robinson <ro...@us.ibm.com>.
>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 will not work according to Axis2 works
>and anyone else using it will find that out the hard way.
>
>That's not an acceptable commit right?
>
>Sanjiva.
Sanjiva,
Committing the code as-is will not disrupt anyone else. The function has to
be explicitly called. I expect to provide an update
to address your concerns over the ServiceContext fairly soon, so I expect
that the
window in which someone could use it and hit that problem will be short.
In this
respect, this is no different from someone using Axis2 and encountering a
problem
and opening a JIRA issue.
If finding someone to do the commit is a problem I would suggest Bill Nagy,
who
already has some familiarity with the message context save/restore code.
Ann
[AXIS2] OMElement.setFirstChild() sometimes breaks the AXIOM tree?
Posted by Toshiro Takase <E3...@jp.ibm.com>.
Hi all,
It is very hard for me to understand the semantics of
OMElement.setFirstChild().
Let's see,,,
-----
OMElement parent = .....
OMElement a = .....
OMElement b = .....
OMElement c = .....
parent.addChild(a);
parent.addChild(b);
parent.addChild(c);
parent.setFirstChild(b);
-----
Then, what happens?
In current implementation, the first child of "parent" is "b".
The previous sibling of "b" is still "a".
The next sibling of "b" is "c"....
Is this correct behavior? Or "b" should be detached in the setFirstChild
method?
Would anyone tell me the correct semantics of setFirstChild method?
Thanks in advance,
Toshiro TAKASE
IBM Research, Tokyo Research Laboratory, Internet Technology
notes ID: Toshiro Takase/Japan/IBM@IBMJP, e-mail: E30809@jp.ibm.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [AXIS2] Proposal for saving the message context
Posted by Ann Robinson <ro...@us.ibm.com>.
>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 will not work according to Axis2 works
>and anyone else using it will find that out the hard way.
>
>That's not an acceptable commit right?
>
>Sanjiva.
Sanjiva,
Committing the code as-is will not disrupt anyone else. The function has to
be explicitly called. I expect to provide an update
to address your concerns over the ServiceContext fairly soon, so I expect
that the
window in which someone could use it and hit that problem will be short.
In this
respect, this is no different from someone using Axis2 and encountering a
problem
and opening a JIRA issue.
If finding someone to do the commit is a problem I would suggest Bill Nagy,
who
already has some familiarity with the message context save/restore code.
Ann
Re: [AXIS2] Proposal for saving the message context
Posted by Ann Robinson <ro...@us.ibm.com>.
>>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 will not work according to Axis2 works
>>and anyone else using it will find that out the hard way.
>>
>>That's not an acceptable commit right?
>>
>>Sanjiva.
>
>On Mon, 2006-12-11, Ann Robinson wrote:
> Sanjiva,
>
> Committing the code as-is will not disrupt anyone else. The function has
to
> be explicitly called. I expect to provide an update
> to address your concerns over the ServiceContext fairly soon, so I expect
that the
> window in which someone could use it and hit that problem will be short.
In this
> respect, this is no different from someone using Axis2 and encountering a
problem
> and opening a JIRA issue.
>
> If finding someone to do the commit is a problem I would suggest Bill
Nagy, who
> already has some familiarity with the message context save/restore code.
>
> Ann
>
Sanjiva,
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 and
used internally so the prototype has reached a level of stability. I think
the risk of
introducing problems to the mainstream message processing is very minimal.
This proposal does not change Axis2 architecture but instead deals with the
existing structure of the Axis2 message context object graph and message
processing.
I would really like to get this proposal at a point where it could be
included
in the Axis2 1.2 release. I am currently working on a solution for the
point
you made regarding the ServiceContext and I will provide an updated
patch.
What are the concerns/issues that are blocking the acceptance of
this proposal?
Ann
Re: [AXIS2] Proposal for saving the message context
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
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 will not work according to Axis2 works
and anyone else using it will find that out the hard way.
That's not an acceptable commit right?
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [AXIS2] Proposal for saving the message context
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
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 will not work according to Axis2 works
and anyone else using it will find that out the hard way.
That's not an acceptable commit right?
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [AXIS2] Proposal for saving the message context
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
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 will not work according to Axis2 works
and anyone else using it will find that out the hard way.
That's not an acceptable commit right?
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [AXIS2] Proposal for saving the message context
Posted by Ann Robinson <ro...@us.ibm.com>.
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 to add to the proposal.
Hi Ann- it seems to me that the current proposal is not in a state to be
committed until this is sorted out because without that part its simply
incorrect and results in creating back a context structure which is no
longer valid.
Sanjiva.
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.
Ann
WebSphere Development, Web Services Engine
IBM
11501 Burnet Rd IZip 9035G021
Austin, TX 78758
(512)838-9438 TL 678-9438
Internet: robinsona @ us.ibm.com
Re: [AXIS2] Proposal for saving the message context
Posted by Ann Robinson <ro...@us.ibm.com>.
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 to add to the proposal.
Hi Ann- it seems to me that the current proposal is not in a state to be
committed until this is sorted out because without that part its simply
incorrect and results in creating back a context structure which is no
longer valid.
Sanjiva.
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.
Ann
WebSphere Development, Web Services Engine
IBM
11501 Burnet Rd IZip 9035G021
Austin, TX 78758
(512)838-9438 TL 678-9438
Internet: robinsona @ us.ibm.com
Re: [AXIS2] Proposal for saving the message context
Posted by Ann Robinson <ro...@us.ibm.com>.
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 to add to the proposal.
Hi Ann- it seems to me that the current proposal is not in a state to be
committed until this is sorted out because without that part its simply
incorrect and results in creating back a context structure which is no
longer valid.
Sanjiva.
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.
Ann
WebSphere Development, Web Services Engine
IBM
11501 Burnet Rd IZip 9035G021
Austin, TX 78758
(512)838-9438 TL 678-9438
Internet: robinsona @ us.ibm.com
Re: [AXIS2] Proposal for saving the message context
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
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 to add to the proposal.
Hi Ann- it seems to me that the current proposal is not in a state to be
committed until this is sorted out because without that part its simply
incorrect and results in creating back a context structure which is no
longer valid.
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [AXIS2] Proposal for saving the message context
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
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 to add to the proposal.
Hi Ann- it seems to me that the current proposal is not in a state to be
committed until this is sorted out because without that part its simply
incorrect and results in creating back a context structure which is no
longer valid.
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [AXIS2] Proposal for saving the message context
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
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 to add to the proposal.
Hi Ann- it seems to me that the current proposal is not in a state to be
committed until this is sorted out because without that part its simply
incorrect and results in creating back a context structure which is no
longer valid.
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [AXIS2] Proposal for saving the message context
Posted by Ann Robinson <ro...@us.ibm.com>.
Hi, Sanjiva,
Thanks for the comments. I have tagged your comments with
<sanjiva>text</sanjiva> to keep the indentation from getting too deep and
put my responses below your comments with the tags <amr2>text</amr2>.
Ann
> <amr>
> 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 the ConfigurationContext object associated with the AxisEngine
> where the MessageContext was restored. So, the *Context objects are
> unique across restored MessageContexts but the Axis* objects are
> easily shared/re-used across restored MessageContexts. A future
> refinement for the save/restore of the MessageContext is to find a way
> to share *Context objects across restored MessageContexts. This is
> actually a fairly small set of objects and involves the
> OperationContext, ServiceContext, and ServiceGroupContext objects.
> </amr>
<sanjiva>
Hmm. I don't think your approach will work if there's any serializable
state the user has put into say ServiceContext and if that state gets
modified by handlers after message reincarnation. There will be two
different service contexts around and the "shared" value will no longer
be shared.
</sanjiva>
<amr2>
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 to add to the proposal.
</amr2>
> 5. How will this map to a environment where somebody wants to save the
> MC in a database. For example Sandesha2 has a StorageManager inferace
> which could be implemented by different storage mechanisms. How will
> you support such a scenario with this.
>
> <amr>
> The MessageContext is saved to an output stream, and the output stream
> can be directed to a variety of mechanisms. A storage mechanism that
> implements the Sandesha2 StorageManager interface could set up an
> output stream that is appropriate for the target database, for
> example, a byte array or a file.
> </amr>
<sanjiva>
Isn't that rather weird?? Writing an object output stream to go to a
database? Maybe its just me (and I don't know anything about databases
so could easily be wrong).
</sanjiva>
<amr2>
While I am not a database expert, I would expect that someone would use
JDBC to access a database and then use an appropriate data structure to
save to and retrieve from the database.
</amr2>
Ann
WebSphere Development, Web Services Engine
IBM
11501 Burnet Rd IZip 9035G021
Austin, TX 78758
(512)838-9438 TL 678-9438
Re: [AXIS2] Proposal for saving the message context
Posted by Ann Robinson <ro...@us.ibm.com>.
Hi, Sanjiva,
Thanks for the comments. I have tagged your comments with
<sanjiva>text</sanjiva> to keep the indentation from getting too deep and
put my responses below your comments with the tags <amr2>text</amr2>.
Ann
> <amr>
> 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 the ConfigurationContext object associated with the AxisEngine
> where the MessageContext was restored. So, the *Context objects are
> unique across restored MessageContexts but the Axis* objects are
> easily shared/re-used across restored MessageContexts. A future
> refinement for the save/restore of the MessageContext is to find a way
> to share *Context objects across restored MessageContexts. This is
> actually a fairly small set of objects and involves the
> OperationContext, ServiceContext, and ServiceGroupContext objects.
> </amr>
<sanjiva>
Hmm. I don't think your approach will work if there's any serializable
state the user has put into say ServiceContext and if that state gets
modified by handlers after message reincarnation. There will be two
different service contexts around and the "shared" value will no longer
be shared.
</sanjiva>
<amr2>
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 to add to the proposal.
</amr2>
> 5. How will this map to a environment where somebody wants to save the
> MC in a database. For example Sandesha2 has a StorageManager inferace
> which could be implemented by different storage mechanisms. How will
> you support such a scenario with this.
>
> <amr>
> The MessageContext is saved to an output stream, and the output stream
> can be directed to a variety of mechanisms. A storage mechanism that
> implements the Sandesha2 StorageManager interface could set up an
> output stream that is appropriate for the target database, for
> example, a byte array or a file.
> </amr>
<sanjiva>
Isn't that rather weird?? Writing an object output stream to go to a
database? Maybe its just me (and I don't know anything about databases
so could easily be wrong).
</sanjiva>
<amr2>
While I am not a database expert, I would expect that someone would use
JDBC to access a database and then use an appropriate data structure to
save to and retrieve from the database.
</amr2>
Ann
WebSphere Development, Web Services Engine
IBM
11501 Burnet Rd IZip 9035G021
Austin, TX 78758
(512)838-9438 TL 678-9438
Re: [AXIS2] Proposal for saving the message context
Posted by Ann Robinson <ro...@us.ibm.com>.
Hi, Sanjiva,
Thanks for the comments. I have tagged your comments with
<sanjiva>text</sanjiva> to keep the indentation from getting too deep and
put my responses below your comments with the tags <amr2>text</amr2>.
Ann
> <amr>
> 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 the ConfigurationContext object associated with the AxisEngine
> where the MessageContext was restored. So, the *Context objects are
> unique across restored MessageContexts but the Axis* objects are
> easily shared/re-used across restored MessageContexts. A future
> refinement for the save/restore of the MessageContext is to find a way
> to share *Context objects across restored MessageContexts. This is
> actually a fairly small set of objects and involves the
> OperationContext, ServiceContext, and ServiceGroupContext objects.
> </amr>
<sanjiva>
Hmm. I don't think your approach will work if there's any serializable
state the user has put into say ServiceContext and if that state gets
modified by handlers after message reincarnation. There will be two
different service contexts around and the "shared" value will no longer
be shared.
</sanjiva>
<amr2>
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 to add to the proposal.
</amr2>
> 5. How will this map to a environment where somebody wants to save the
> MC in a database. For example Sandesha2 has a StorageManager inferace
> which could be implemented by different storage mechanisms. How will
> you support such a scenario with this.
>
> <amr>
> The MessageContext is saved to an output stream, and the output stream
> can be directed to a variety of mechanisms. A storage mechanism that
> implements the Sandesha2 StorageManager interface could set up an
> output stream that is appropriate for the target database, for
> example, a byte array or a file.
> </amr>
<sanjiva>
Isn't that rather weird?? Writing an object output stream to go to a
database? Maybe its just me (and I don't know anything about databases
so could easily be wrong).
</sanjiva>
<amr2>
While I am not a database expert, I would expect that someone would use
JDBC to access a database and then use an appropriate data structure to
save to and retrieve from the database.
</amr2>
Ann
WebSphere Development, Web Services Engine
IBM
11501 Burnet Rd IZip 9035G021
Austin, TX 78758
(512)838-9438 TL 678-9438
Re: [AXIS2] Proposal for saving the message context
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Hi Ann,
> <amr>
> 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 the ConfigurationContext object associated with the AxisEngine
> where the MessageContext was restored. So, the *Context objects are
> unique across restored MessageContexts but the Axis* objects are
> easily shared/re-used across restored MessageContexts. A future
> refinement for the save/restore of the MessageContext is to find a way
> to share *Context objects across restored MessageContexts. This is
> actually a fairly small set of objects and involves the
> OperationContext, ServiceContext, and ServiceGroupContext objects.
> </amr>
Hmm. I don't think your approach will work if there's any serializable
state the user has put into say ServiceContext and if that state gets
modified by handlers after message reincarnation. There will be two
different service contexts around and the "shared" value will no longer
be shared.
> 5. How will this map to a environment where somebody wants to save the
> MC in a database. For example Sandesha2 has a StorageManager inferace
> which could be implemented by different storage mechanisms. How will
> you support such a scenario with this.
>
> <amr>
> The MessageContext is saved to an output stream, and the output stream
> can be directed to a variety of mechanisms. A storage mechanism that
> implements the Sandesha2 StorageManager interface could set up an
> output stream that is appropriate for the target database, for
> example, a byte array or a file.
> </amr>
Isn't that rather weird?? Writing an object output stream to go to a
database? Maybe its just me (and I don't know anything about databases
so could easily be wrong).
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [AXIS2] Proposal for saving the message context
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Hi Ann,
> <amr>
> 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 the ConfigurationContext object associated with the AxisEngine
> where the MessageContext was restored. So, the *Context objects are
> unique across restored MessageContexts but the Axis* objects are
> easily shared/re-used across restored MessageContexts. A future
> refinement for the save/restore of the MessageContext is to find a way
> to share *Context objects across restored MessageContexts. This is
> actually a fairly small set of objects and involves the
> OperationContext, ServiceContext, and ServiceGroupContext objects.
> </amr>
Hmm. I don't think your approach will work if there's any serializable
state the user has put into say ServiceContext and if that state gets
modified by handlers after message reincarnation. There will be two
different service contexts around and the "shared" value will no longer
be shared.
> 5. How will this map to a environment where somebody wants to save the
> MC in a database. For example Sandesha2 has a StorageManager inferace
> which could be implemented by different storage mechanisms. How will
> you support such a scenario with this.
>
> <amr>
> The MessageContext is saved to an output stream, and the output stream
> can be directed to a variety of mechanisms. A storage mechanism that
> implements the Sandesha2 StorageManager interface could set up an
> output stream that is appropriate for the target database, for
> example, a byte array or a file.
> </amr>
Isn't that rather weird?? Writing an object output stream to go to a
database? Maybe its just me (and I don't know anything about databases
so could easily be wrong).
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [AXIS2] Proposal for saving the message context
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Hi Ann,
> <amr>
> 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 the ConfigurationContext object associated with the AxisEngine
> where the MessageContext was restored. So, the *Context objects are
> unique across restored MessageContexts but the Axis* objects are
> easily shared/re-used across restored MessageContexts. A future
> refinement for the save/restore of the MessageContext is to find a way
> to share *Context objects across restored MessageContexts. This is
> actually a fairly small set of objects and involves the
> OperationContext, ServiceContext, and ServiceGroupContext objects.
> </amr>
Hmm. I don't think your approach will work if there's any serializable
state the user has put into say ServiceContext and if that state gets
modified by handlers after message reincarnation. There will be two
different service contexts around and the "shared" value will no longer
be shared.
> 5. How will this map to a environment where somebody wants to save the
> MC in a database. For example Sandesha2 has a StorageManager inferace
> which could be implemented by different storage mechanisms. How will
> you support such a scenario with this.
>
> <amr>
> The MessageContext is saved to an output stream, and the output stream
> can be directed to a variety of mechanisms. A storage mechanism that
> implements the Sandesha2 StorageManager interface could set up an
> output stream that is appropriate for the target database, for
> example, a byte array or a file.
> </amr>
Isn't that rather weird?? Writing an object output stream to go to a
database? Maybe its just me (and I don't know anything about databases
so could easily be wrong).
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [AXIS2] Proposal for saving the message context
Posted by Ann Robinson <ro...@us.ibm.com>.
Chamikara,
Thanks for your questions. My responses are below and are delimited with
<amr>text</amr>.
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 be a big waste of the storage.
<amr>
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 the
ConfigurationContext object associated with the AxisEngine where the
MessageContext was restored. So, the *Context objects are unique across
restored MessageContexts but the Axis* objects are easily shared/re-used
across restored MessageContexts. A future refinement for the save/restore
of the MessageContext is to find a way to share *Context objects across
restored MessageContexts. This is actually a fairly small set of objects
and involves the OperationContext, ServiceContext, and ServiceGroupContext
objects.
</amr>
2. ConfigurationContext
I'm not sure on how the information in the ConfigurationContext will be
serialized. You haven't mentioned in the list of contexts that get saved
with the MessageContext. But this may also contain useful runtime data
which may be needed by the entity that uses the MessageContext.
<amr>
The ConfigurationContext object is not currently saved with the
MessageContext object graph. The restored MessageContext gets an active
ConfigurationContext from the environment where the restoration of the
MessageContext takes place. If the runtime data in the
ConfigurationContext object needs to be preserved for the MessageContext,
then this work would need to be added to the current implementation. So
far, in testing the current implementation of the save/restore of the
MessageContext, it hasn't been a problem - although it could be a
consideration for more complex application environments. Any advice on
this would be appreciated.
</amr>
3. What actually happens in the
'msgContext2.activate(configurationContext)' method.
<amr>
Since only a subset of the MessageContext object graph is saved during
serialization, the deserialization of a saved MessageContext only
reconstitutes a subset of the MessageContext object graph. In order to
re-establish the full MessageContext object graph, the restored
MessageContext object needs to be called with an active
ConfigurationContext object that is appropriate for the AxisEngine where
the deserialization is taking place. This is the
MessageContext.activate(ConfigurationContext configCtx) method. The
MessageContext.activate() method uses some metadata that was saved/restored
to re-establish the links to the appropriate Axis* objects. The metadata
typically corresponds to the name associated with the Axis* object. The
MessageContext.activate() also handles reconciling the phase/handler chain
information that is kept in the MessageContext object.
</amr>
4. As a whole your aproach is on making MessageContext implement
Externalizable right ?
<amr>
Yes, the java.io.Externalizable interface provides flexibility to customize
what is saved and how it is restored, which is needed to handle the complex
object graph associated with a MessageContext. The java.io.Serializable
interface is better for a simple object or for an object that has a simpler
object graph.
</amr>
5. How will this map to a environment where somebody wants to save the MC
in a database. For example Sandesha2 has a StorageManager inferace which
could be implemented by different storage mechanisms. How will you support
such a scenario with this.
<amr>
The MessageContext is saved to an output stream, and the output stream can
be directed to a variety of mechanisms. A storage mechanism that
implements the Sandesha2 StorageManager interface could set up an output
stream that is appropriate for the target database, for example, a byte
array or a file.
</amr>
Ann
WebSphere Development, Web Services Engine
IBM
11501 Burnet Rd IZip 9035G021
Austin, TX 78758
(512)838-9438 TL 678-9438
Lotus Notes: Ann Robinson/Austin/IBM@IBMUS
Internet: robinsona @ us.ibm.com
Re: [AXIS2] Proposal for saving the message context
Posted by Ann Robinson <ro...@us.ibm.com>.
Chamikara,
Thanks for your questions. My responses are below and are delimited with
<amr>text</amr>.
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 be a big waste of the storage.
<amr>
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 the
ConfigurationContext object associated with the AxisEngine where the
MessageContext was restored. So, the *Context objects are unique across
restored MessageContexts but the Axis* objects are easily shared/re-used
across restored MessageContexts. A future refinement for the save/restore
of the MessageContext is to find a way to share *Context objects across
restored MessageContexts. This is actually a fairly small set of objects
and involves the OperationContext, ServiceContext, and ServiceGroupContext
objects.
</amr>
2. ConfigurationContext
I'm not sure on how the information in the ConfigurationContext will be
serialized. You haven't mentioned in the list of contexts that get saved
with the MessageContext. But this may also contain useful runtime data
which may be needed by the entity that uses the MessageContext.
<amr>
The ConfigurationContext object is not currently saved with the
MessageContext object graph. The restored MessageContext gets an active
ConfigurationContext from the environment where the restoration of the
MessageContext takes place. If the runtime data in the
ConfigurationContext object needs to be preserved for the MessageContext,
then this work would need to be added to the current implementation. So
far, in testing the current implementation of the save/restore of the
MessageContext, it hasn't been a problem - although it could be a
consideration for more complex application environments. Any advice on
this would be appreciated.
</amr>
3. What actually happens in the
'msgContext2.activate(configurationContext)' method.
<amr>
Since only a subset of the MessageContext object graph is saved during
serialization, the deserialization of a saved MessageContext only
reconstitutes a subset of the MessageContext object graph. In order to
re-establish the full MessageContext object graph, the restored
MessageContext object needs to be called with an active
ConfigurationContext object that is appropriate for the AxisEngine where
the deserialization is taking place. This is the
MessageContext.activate(ConfigurationContext configCtx) method. The
MessageContext.activate() method uses some metadata that was saved/restored
to re-establish the links to the appropriate Axis* objects. The metadata
typically corresponds to the name associated with the Axis* object. The
MessageContext.activate() also handles reconciling the phase/handler chain
information that is kept in the MessageContext object.
</amr>
4. As a whole your aproach is on making MessageContext implement
Externalizable right ?
<amr>
Yes, the java.io.Externalizable interface provides flexibility to customize
what is saved and how it is restored, which is needed to handle the complex
object graph associated with a MessageContext. The java.io.Serializable
interface is better for a simple object or for an object that has a simpler
object graph.
</amr>
5. How will this map to a environment where somebody wants to save the MC
in a database. For example Sandesha2 has a StorageManager inferace which
could be implemented by different storage mechanisms. How will you support
such a scenario with this.
<amr>
The MessageContext is saved to an output stream, and the output stream can
be directed to a variety of mechanisms. A storage mechanism that
implements the Sandesha2 StorageManager interface could set up an output
stream that is appropriate for the target database, for example, a byte
array or a file.
</amr>
Ann
WebSphere Development, Web Services Engine
IBM
11501 Burnet Rd IZip 9035G021
Austin, TX 78758
(512)838-9438 TL 678-9438
Lotus Notes: Ann Robinson/Austin/IBM@IBMUS
Internet: robinsona @ us.ibm.com
Re: [AXIS2] Proposal for saving the message context
Posted by Ann Robinson <ro...@us.ibm.com>.
Chamikara,
Thanks for your questions. My responses are below and are delimited with
<amr>text</amr>.
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 be a big waste of the storage.
<amr>
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 the
ConfigurationContext object associated with the AxisEngine where the
MessageContext was restored. So, the *Context objects are unique across
restored MessageContexts but the Axis* objects are easily shared/re-used
across restored MessageContexts. A future refinement for the save/restore
of the MessageContext is to find a way to share *Context objects across
restored MessageContexts. This is actually a fairly small set of objects
and involves the OperationContext, ServiceContext, and ServiceGroupContext
objects.
</amr>
2. ConfigurationContext
I'm not sure on how the information in the ConfigurationContext will be
serialized. You haven't mentioned in the list of contexts that get saved
with the MessageContext. But this may also contain useful runtime data
which may be needed by the entity that uses the MessageContext.
<amr>
The ConfigurationContext object is not currently saved with the
MessageContext object graph. The restored MessageContext gets an active
ConfigurationContext from the environment where the restoration of the
MessageContext takes place. If the runtime data in the
ConfigurationContext object needs to be preserved for the MessageContext,
then this work would need to be added to the current implementation. So
far, in testing the current implementation of the save/restore of the
MessageContext, it hasn't been a problem - although it could be a
consideration for more complex application environments. Any advice on
this would be appreciated.
</amr>
3. What actually happens in the
'msgContext2.activate(configurationContext)' method.
<amr>
Since only a subset of the MessageContext object graph is saved during
serialization, the deserialization of a saved MessageContext only
reconstitutes a subset of the MessageContext object graph. In order to
re-establish the full MessageContext object graph, the restored
MessageContext object needs to be called with an active
ConfigurationContext object that is appropriate for the AxisEngine where
the deserialization is taking place. This is the
MessageContext.activate(ConfigurationContext configCtx) method. The
MessageContext.activate() method uses some metadata that was saved/restored
to re-establish the links to the appropriate Axis* objects. The metadata
typically corresponds to the name associated with the Axis* object. The
MessageContext.activate() also handles reconciling the phase/handler chain
information that is kept in the MessageContext object.
</amr>
4. As a whole your aproach is on making MessageContext implement
Externalizable right ?
<amr>
Yes, the java.io.Externalizable interface provides flexibility to customize
what is saved and how it is restored, which is needed to handle the complex
object graph associated with a MessageContext. The java.io.Serializable
interface is better for a simple object or for an object that has a simpler
object graph.
</amr>
5. How will this map to a environment where somebody wants to save the MC
in a database. For example Sandesha2 has a StorageManager inferace which
could be implemented by different storage mechanisms. How will you support
such a scenario with this.
<amr>
The MessageContext is saved to an output stream, and the output stream can
be directed to a variety of mechanisms. A storage mechanism that
implements the Sandesha2 StorageManager interface could set up an output
stream that is appropriate for the target database, for example, a byte
array or a file.
</amr>
Ann
WebSphere Development, Web Services Engine
IBM
11501 Burnet Rd IZip 9035G021
Austin, TX 78758
(512)838-9438 TL 678-9438
Lotus Notes: Ann Robinson/Austin/IBM@IBMUS
Internet: robinsona @ us.ibm.com