ws-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From George I Matkovits <matkovi...@uswest.net>
Subject Re: JDOM vs DOM (was: Re: IRC chat log)
Date Fri, 03 Nov 2000 15:34:28 GMT
Yes. Please visit http://jdom.org
Regards - George

Rich Johns wrote:

> I assume JDOM is public domain, no strings attached?
>
> "Nelson, Christopher" wrote:
>
> > I would like to weigh in on the side of JDOM.  I've been using it for awhile
> > and have also found it to be a very much more usable API for Java XML
> > development than straight DOM.  Here's what I've seen several times: XML
> > projects that use DOM generally have to build utility classes like DOMUtils
> > because DOM is so painful to use.  I think of JDOM as a standardized
> > DOMUtils.  I've also found it fairly easy to convert between the two.  While
> > I would agree that we do not want to force SOAP users to use JDOM, we do not
> > want to preclude the use of JDOM within the code where it makes sense to use
> > it.  I think we want to have interfaces points always expose DOM, but if
> > some code uses JDOM internally to deal with XML, I don't think this should
> > be forbidden.
> >
> > -----Original Message-----
> > From: George I Matkovits [mailto:matkovitsg@uswest.net]
> > Sent: Wednesday, November 01, 2000 2:48 PM
> > To: soap-dev@xml.apache.org
> > Subject: Re: JDOM vs DOM (was: Re: IRC chat log)
> >
> > I would like to add my 2 cents worth for JDOM
> > 1.) I am  in complete agreement with Sanjiva about standards and the use of
> > SAX
> > for handling 'large' payloads BUT
> > 2.) JDOM: the DOM in JDOM does not mean it is based on DOM, it is NOT! It is
> > a
> > Java wrapper around SAX/DOM classes and data structures.:-) JDOM is a very
> > Java
> > friendly API, I LOVE IT and there is also a good and comprehensive book.
> > JDOM
> > allows 'Java training wheel' access to XML for XML newbies like I (IMHO much
> > better then JAXP). I also noticed that there are many, many of us on the
> > various
> > xml related lists. Some combination of the two technologies (SAX and JDOM),
> > where JDOM access to SOAP APIs would be relatively easy, IMHO would be very
> > nice
> > and would enhance Apache (IBM) SOAP's ease of acceptance over of that from
> > the
> > 'evil empire'. Also IMHO a JDOM friendly WSToolKit would add greatly to the
> > future acceptance  of Java as the 'defacto' Internet Business Environment. I
> > wish that Sun would also understand this. (-: They seem to have great
> > difficulty
> > in understanding the world outside the LAN cocoon unlike MS)
> > Regards - George
> >
> > Sanjiva Weerawarana wrote:
> >
> > > > I think the concern with DOM (one which you put forth as well, if I
> > recall
> > > > correctly) is that it's rather a memory-hog, and is a bit too
> > heavyweight
> > > > for a lot of the use-cases.
> > >
> > > Yes, I put it forth too as a concern as the *output of serializers.*
> > >
> > > The problem with DOM is (mostly) the implementation. The APIs are designed
> > > to support "live" edits and monitoring, so the API force certain impl
> > > requirements too. The real problem is the performance (memory usage)
> > > of a full DOM impl *when one is not needed*. I would argue that Apache
> > SOAP
> > > is a case where a full live impl is not needed: once the envelope is
> > parsed
> > > its not going to change while a filter is operating.
> > >
> > > The solution IMO is to use SAX as appropriate and an efficient impl of
> > > the DOM that is customized for our needs. What I am opposed to is exposing
> > > a non-standard API, even if it means a performance hit. Let's be
> > realistic,
> > > JDOM vs a good DOM will not mean a 50% performance difference not
> > > reasonable sized messages. For large messages, the *only* real option is
> > > to use SAX. Anything else is nuts.
> > >
> > > Sanjiva.


Mime
View raw message