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
|