geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@coredevelopers.net>
Subject Re: [XML Parsing]
Date Mon, 01 Sep 2003 23:26:49 GMT

On Monday, September 1, 2003, at 05:39 PM, Jan Bartel wrote:

> Apropos of Aaron's plea (see blow), I know I voted +1 for POJOs, but 
> considering it a little more and given the difficulties experienced, 
> are we sure that this is a necessary approach?
>
> 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 need them.  I am writing a Dynamic MBean which generated the 
MBean*Info objects from an xml file.  These objects are very specific 
and must be sub classes of the MBean*Info classes (they are classes and 
not interfaces).

As an aside I prefer to write my own beans.  We get much better control 
and it is easy (and fast) with a decent IDE.

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

IIRC there is an XPath project that will query over a pojo graph.

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

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.

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

oops above :-)

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

>    + must support xpath

Unless we can get outboard xpath over pojos support.

>    + nice if object <-> DOM was easily available

What do you mean?

-dain


Mime
View raw message