Re: [XML Parsing]

[Jan Bartel]

Dain Sundstrom wrote:
<snip>
  + Web deployment:
    the concrete web containers (eg Jetty, Tomcat) deal with xml
    descriptors anyway, so they already DOM-ify them. This in fact
    leads to double parsing of web.xml descriptors: once by geronimo
    and once by the container. This could be optimised by modifying
    Jetty and Tomcat to operate on a DOM version of web.xml instead.
    However, if geronimo moves to POJO representations of the
    descriptors, then such a modification wouldn't be possible (or
    we'd have to introduce a POJO->DOM conversion).

(No offense ment here) I have always considered this a design problem 
with web containers.  Why do I have to generate some xml to deploy a 
servlet?  I should be able to create some pojo data structures and tell 
the deployer to "do it".  Anyway, that is an issue for another day...
No offense taken :-)  The reason they all deal with xml descriptors is 
purely because the spec mandates it.

For now, I think we make an exception for the web containers, but for 
every thing else I think the metadata should be passed around in pojos. 
 That way users will be able to deploy ejb and message queues on the fly.
Not sure I'm with you here, why does on-the-fly deployment require 
POJOs? If we pass a DOM of some kind around, representing the deployment 
descriptors:

  + the DOM can be constructed either from xml or on the fly
  + we've already got all the jars necessary to support it in
    geronimo's /lib
  + there are efficiencies to be gained, at least in the web
    deployer/container area by using DOMs

So can we enumerate the advantages of a non-DOM representation of the
deployment descriptors?

oops above :-)
Well, it was a start at least :-)

Other requirements for whatever representation of the deployment 
descriptors we choose should include:

   + must be fast translating object <-> xml

Well how fast?  All of the parsing happens during deployment time, so it 
is not on the invocation critical path.  Deployment should be fast, but 
it does not need to be eyeblink fast.
True.

   + must require minimum supporting jars (we *must* avoid /lib bloat)

+100  All of the frameworks we are looking at are huge.  I personally 
think we have the best option with XMLBeans as it will be an apache 
project.
(One of) my pet peeves is bloat in the number of jars required just to 
get a "Hello World" happening. It would be great if geronimo was lean 
and mean (without of course sacrificing functionality).

   + must support xpath

Unless we can get outboard xpath over pojos support.
Yes. I believe there is at least one Jakarta xpath-for-POJO project. I 
don't have any experience with it and I was hoping someone on this list
might contribute their evaluation of it.


   + nice if object <-> DOM was easily available

What do you mean?
I mean I still haven't given up on trying to stop the web containers
double or triple parsing the descriptors, so I want the option to be
able to pass them in a pre-parsed DOM. If we use POJOs then my only
way of doing that is if there is POJO -> DOM.
cheers,
Jan