On Thu, 2006-12-21 at 11:14 -0600, Ann Robinson wrote: > I have submitted an updated patch for the message context save/restore > proposal (under JIRA axis2-1567). Now, when a message context is > restored, it looks for existing ServiceContext and ServiceGroupContext > objects to use in its object hierarchy. This means that a restored > object graph for a MessageContext is made up of mostly existing > *Context and Axis* objects. In other words, object re-use for the > *Context and Axis* objects is maximized. And, when existing context > object are re-used, any saved properties are merged into the existing > objects. > > Just to summarize, when a message context is saved, its state is > collected and saved, including: > - the settings for various flags in the message context > - properties associated with the message context (which are really > contained in an Options object) > - the actual message > - where in the message processing the message is > - meta data about the handlers associated with processing the message > - meta data about the AxisOperation/AxisService/AxisServiceGroup > associated with the message context > - the OperationContext/ServiceContext/ServiceGroupContext associated > with the message context
As far as I can see none of this data is private to a message context; so the answer to the question I asked earlier appears to be that this code can perfectly well live in a utility class. > When a message context is restored, the message context object graph > is re-built based on the information that was saved. If possible, > existing objects are used from the engine where the message context is > being restored. Names or IDs are used to find existing objects that > correspond to their counterparts from the saved environment. Where > existing objects are used, saved properties are merged into the > existing objects. I'm confused. What do you mean by existing objects? A particular message exchange lives within a particular service context. You can't just put it back into some exiting object; it must go back into the corresponding service context etc.. is that what you mean? If so how do you record the ID of the service context object? Two different message contexts saved during two save actions could refer to the same service context with different state values of course. > The message context save/restore proposal is intended to benefit > AXIS2. This proposal gives AXIS2 some functionality that allows AXIS2 > to be used in more customer environments. > > I have indicated in previous postings that the prototype for the > message context save/restore proposal has been used internally by IBM. > This statement was not intended to divide the open source community > along company lines but instead, to indicate that the prototype has > been tested and reached a level of stability and that negative > side-effects have been minimized. Absolutely. As I stated earlier, there's nothing wrong with providing hooks that help people who build on top of Axis2. However, the concern I have with this proposal is that its being proposed at a generic level when what appears to be needed is a solution that works within the constrained world of WS-RM. Unless I missed something, this same proposal can live just fine as FooUtil.writeObject (MC, ..) instead of mc.writeObject (..). I'd like an answer on why that's not possible. > I would really like to get this proposal at a point where it could be > included in the AXIS2 1.2 release. What other technical or > architectural issues need to be addressed? See above. 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
