That is, do we have a clear set of use-cases and requirements that are met by POJOs or in fact a non-DOM model? I'm not against some POJO etc representation of the deployment descriptors, I just think we need to clearly understand the reasons why we need them.
I haven't actually seen any compelling use-cases yet - the ones I can enumerate would be better served by dealing directly with a DOM :
+ JSR88 deployment:
the purpose of JSR88 beans is to deal with xml deployment
descriptors. They need to perform xpath matching. + 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).
So can we enumerate the advantages of a non-DOM representation of the deployment descriptors?
Other requirements for whatever representation of the deployment descriptors we choose should include:
+ must be fast translating object <-> xml + must require minimum supporting jars (we *must* avoid /lib bloat) + must support xpath + nice if object <-> DOM was easily available
regards Jan
Aaron Mulder wrote: <snip>
Also, the profusion of commons libraries required to get this running is a little frustrating.
Can we just use DOM please?
