geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Bartel <>
Subject Re: [XML Parsing]
Date Tue, 02 Sep 2003 11:31:42 GMT
Dain Sundstrom wrote:
>>   + 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 

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

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


View raw message