axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Peshansky <ig...@us.ibm.com>
Subject Re: [Axis2] Decoupling dispatch/invocation from XML parsing/construction
Date Thu, 06 Apr 2006 01:28:53 GMT
Sanjiva Weerawarana wrote on 04/05/2006 09:04:57 PM:

> On Wed, 2006-04-05 at 13:38 -0400, Igor Peshansky wrote:
> > Is there a way to do this, or will Axis2 always parse the body using
> > its own parser?  FWIW, it's not good enough for us to get access to 
the
> > XMLStreamReader (which is StAX, IIRC) -- we have our own parser that 
we'll
> > need to use.  And yes, I'm aware that we'll have to reimplement the
> > security subsystem in this case.  Basically, how much of the Axis2 
code,
> > in your estimation, will we be able to reuse?
> 
> (Hi Igor .. pls say hi to Mukund for me :-))

Thanks for the reply, Sanjiva.  Will do. :-)

> So .. I don't think there's a way to make this work for you. Its not
> really about the parser- its about the information model we use to
> represent SOAP messages. We use AXIOM; that's not a pluggable component
> in any way. 

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).

> The only thing you might do is do your own Axiom impl instead of ours
> and have it front whatever your XML Infoset model you use in XJ. Axiom
> assumes that its built with StAX but if you write your own impl there's
> nothing that stops you from building it using another mechanism and then
> fitting into Axis2. 

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.

Now, if only I could get my hands on the raw InputStream of the message...
Looks like I'll have to reimplement HTTPTransportUtils, at the very least.

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.

Thanks for this discussion -- this is really helping me clarify my
understanding of what I should do.
        Igor
-- 
Igor Peshansky  (note the spelling change!)
IBM T.J. Watson Research Center
XJ: No More Pain for XML?s Gain (http://www.research.ibm.com/xj/)


Mime
View raw message