axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Davis" <>
Subject RE: Issues with current AXIS
Date Fri, 20 Jul 2001 18:13:14 GMT
Leaving the SAX/DOM discussion aside for a moment - what's the
best way for David to manipulate the message itself from within his
handler? That question seems to have been overlooked.
He needs to add/remove headers and change the body.
Which classes/methods (or even better - sample code) should he
be looking at?

Glen Daniels <> on 07/20/2001 02:06:56 PM

Please respond to

To:   "''" <>
Subject:  RE: Issues with current AXIS

To add to what Sam said:

I do agree that DOM (and JDOM, for that matter) is a standard form which
people will want to use to manipulate XML data, and that Axis should
probably provide tools for helping developers do just that.  We already
some of that tooling, in that we happily build DOM out of the contents of
the Body element to hand to your messaging implementation class (see the
AdminService in Axis for an example).  This could easily be extended to
allow DOM/JDOM access to arbitrary headers, or even the whole message.

That said, the current Axis Message model is designed to help you search
for, manipulate, and add headers/bodies to messages, using our own APIs.
is still under development, and we would appreciate any feedback/comments
you might have.

+1 on isRoot - I'll fix that (if Sam hasn't already gotten to it :)).


> -----Original Message-----
> From: Sam Ruby []
> Sent: Friday, July 20, 2001 1:56 PM
> To:
> Subject: Re: Issues with current AXIS
> If you look at the design for contemporary XML parsers, you
> will see that
> they parse an input stream using an event driven mechanism
> called SAX, from
> which they produce higher level constructs - namely DOM or
> JDOM or DOM4J or
> whatever.
> Apache Axis is designed to directly process these SAX events.
>  That does
> not preclude being assembled into those higher level
> constructs later if
> your application is not performance sensitive.  If, however,
> you care about
> performance issues, then you should consider using SAX, which
> is an equally
> standard API.
> I would avoid strings.
> I do agree that bean design guidelines would indicate that
> "isRoot" is a
> better name than "getRoot" for a method which returns a boolean.
> - Sam Ruby

View raw message