Hi Matt, I was assuming that the MC serialization code will be used in a Persistent StorageManager. Why are you hoping to use it in the In-Memory StorageManager. (since all other RM state is anyway in-memory).
Chamikara On 1/17/07, Matthew Lovett <[EMAIL PROTECTED]> wrote:
Hi all, Now that Axis2 contains methods to save and restore message context instances, I'd like to start using that code from Sandesha. A the same time, I appreciate that some of you are happy with the status quo, where we insert a dummy transport, and just persist the soap envelope. What I'd like to do is find a way for the 2 approaches to coexist. One obvious option is to create a branch and do the work there, but there is a real risk that not many people would look at or use that branch, and the pain of keeping it up to date could get tiresome. Also, I'm not sure that we'd ever plan to replace the trunk with that branch, as I think there will always be users who are happy with the soap envelope solution. Another option is to create a second in-memory storage manager, but there is so much common code that this would probably lead to a lot of overhead too. I think my preferred option is to put a config flag into the module xml, and modify the storage manager and runtime to check that flag... we can then have admin control of the transport switching & use of the serialization code. Does that sound like a reasonable direction to take? If so then I'll open a Jira and start attaching patches... but I'll hold off committing anything until we get some discussion on the list. Thanks Matt --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
