Hi Chamikara, The security module that we are using is not tolerant of being invoked more than once for the same outbound message. That means that we use the dummy transport & serialise the soap message we invoke security before storing the message, and we re-invoke it when we actually send the message off the box. You could argue that we should change our security module, but there is a general issue here too. We want to tackle this issue by using the serialisation code, and removing the dummy transport.
We feel that using the serialisation code, along with careful use of suspend() and resume() on the message context fits in better with the axis processing model than using the dummy transport. Conversely, we think that the current code that knows about 'retransmittable phases' and forces in the sandesha transport is a bit inelegant. I think that we can make both approaches coexist - should I go on and produce a patch so that you see what I mean? Thanks Matt "Chamikara Jayalath" <[EMAIL PROTECTED]> wrote on 17/01/2007 11:36:32: > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
