On Wed, 2006-04-05 at 21:28 -0400, Igor Peshansky wrote: > > Hmm, the way I see it, it *is* about the parser (and the in-memory message > content representation). Axis2 needs to parse the SOAP envelope to > extract > (and dispatch based upon) the service and operation information. However, > the message content is what's presented to the programmer -- Axis2 doesn't > deal with it in any way other than parse it into Axiom. There is no > reason > some other parser could not be employed for the message content (other > than > the deep integration of Axiom into Axis2).
I'm afraid Axiom is a core part of Axis2 .. its not a removable component. I don't think I grok what you're saying. > Hmm. That might be a bit problematic (not to mention time-consuming)... > It would probably be easier to parse the message (including the SOAP > envelope) on the side, and then construct just those bits of Axiom that > are needed by Axis2 for dispatching messages. And even that may not be > necessary if I construct the resolved MessageContext myself. The MessageContext *must* have an Axiom object in it .. its not an option to replace that. > If I did manage to refactor the code so that message parsing could be > decoupled from operation dispatch, would there be interest in getting that > code into the Axis2 codebase? Keep in mind, though, that it might require > a pretty invasive set of changes. There's no interest in removing Axiom :). I just don't understand what you mean by decoupling parsing from dispatch .. there's absolutely no call to any parsing stuff from dispatch anyway! Clearly we're not talking about the same thing. Sanjiva.
