Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
Message-ID: <3F547F9E.6070903@mortbay.com>
Date: Tue, 02 Sep 2003 21:31:42 +1000
From: Jan Bartel <janb@mortbay.com>
Reply-To: janb@mortbay.com
Organization: Mort Bay Consulting
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.3) Gecko/20030430 Debian/1.3-5
MIME-Version: 1.0
To: geronimo-dev@incubator.apache.org
Subject: Re: [XML Parsing]
References: <C28C6C0E-DCD3-11D7-A2AE-000393DB559A@coredevelopers.net>
In-Reply-To: <C28C6C0E-DCD3-11D7-A2AE-000393DB559A@coredevelopers.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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