ws-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Noel Gadreau <>
Subject Re: JDOM vs DOM (was: Re: IRC chat log)
Date Thu, 02 Nov 2000 17:32:52 GMT
See my comments inline


Sanjiva Weerawarana wrote:
> I'm not talking about write access to the tree. The DOM has a model
> where if someone has a view of a DOM (via an iterator or something)
> then if a write occurs that must be reflected in previously existing
> views too. That is all view are all live all the time. [I forget the
> details a bit now, but I can find out if needed .. one of the guys
> who was in my group at the time, Joe Kesselman, is a big DOM dude.]

I am not sure we would be using these "views" (a Handler will do what it
needs to and then pass the tree along).


> For the particular use case you mentioned I would say neither the DOM or
> the JDOM is the right thing - if this filter needs to forward on the
> message then it should "pass through" the SAX events while it builds
> *whatever the representation* it wants and needs for itself. That is,
> if this filter is say the RPC method invoker, then it could build the
> appropriately typed Java objects out of the SAX stream directly without
> first going through a DOM or JDOM tree. However, if we wanted to provide
> an API where a tree representation of the message was built and passed
> around, then IMO we must use the DOM APIs for that tree, hopefully with
> an efficient, suitably restricted, implementation.

I agree that if a filter/handler just forward, the optimal is just to
pass SAX events. My experience is that some handlers will do that (just
reading information and do something about it) and some will need to
modify the tree (like an encryption/decryption handler).

Note that both the original message and the response are subject to
possible change by handlers.

I agree with you that JDOM is probably the "universal" DOMUtils. I had a
quick glance at the API and it seems that it is based on top of DOM.
(can anybody with more clue than me confirm/deny this ??). If so, it
means we will need to have DOM anyway.

I am also a bit afraid that we start working on something that is not
the core of Apache-SOAP. I think that a flexible engine is needed soon
because the current implementation shows some limits. I would rather
concentrate on delivering a flexible SOAP engine that enables people to
deal easily with headers, special handlers, providers (EJB, ...) than
spent too much time on an XML DOM/JDOM/JDOM++/SAX2JDOM work. This does
not mean that I want to rush 3.0 out, but I am just trying to focus on
one set of problems.

> Sanjiva.

View raw message