geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <>
Subject Re: [vote] XML Parsing
Date Wed, 03 Sep 2003 16:27:50 GMT
On Wednesday, September 3, 2003, at 04:45  pm, Dain Sundstrom wrote:
> On Wednesday, September 3, 2003, at 08:07 AM, James Strachan wrote:
>> On Tuesday, September 2, 2003, at 11:22  pm, Dain Sundstrom wrote:
>>> On Tuesday, September 2, 2003, at 07:44 AM, James Strachan wrote:
>>>> On Tuesday, September 2, 2003, at 12:56  am, Dain Sundstrom wrote:
>>>>> I think we should just use Digester directly.
>>>> Why?
>>> The introspection makes me wary.  If they change the rules, all of  
>>> our stuff breaks.
>> What do you mean 'they'. We're talking about getters, setters & adder  
>> methods here. I can't see the Java Beans spec changing any time soon.
> By they I mean the people writing Betwixt.

We write Betwixt (i.e. Apache folks). I'm the guilty person who started  
it. Be that as it may - I don't see the introspection rules changing  
ever for backwards compatibility (unless explicitly configured to be  

> You are implying there is a simple well understood mapping between xml  
> and java beans.

Yes. Which can be overridden either at the digester level or at the  
betwixt level with a simple XML config file on a per class basis.

>  XML names tend to have dashes in them and some times the structure of  
> the (spec) documents is not how you want you beans.

There's a little pluggable strategy called NameMapper for this kind of  

so if you just add a HyphenatedNameMapper onto your XMLIntrospector  
it'll all just work. I suspect the same XMLIntrospector will work for  
all the 7 XSDs

>>>  Besides that, I think the "digester glue" code you complain about  
>>> below is simple to read and understand.
>> Go right ahead if you want - I'm just offering us not having to write  
>> 7 different digesters for the 7 J2EE schemas.
> Relax James, it is not a big deal.

Ditto - I don't personally care either way. I was just trying to avoid  
the work to write 7 Digesters.

> It is like typeing in the API interfaces; it is a few hours of work up  
> front and you get a lot more control.

Same control. Just more redundant code. But I really don't mind. Go  
pure digester if you like.

>>> What happens when you have exceptions and non trivial mappings.  For  
>>> example, I have a place where I named an xml attribute named  
>>> "class", but the class attribute is named "name" because the spec  
>>> calls it that (and the spec is wrong).
>> Betwixt just makes a special kind of Digester. Its still a Digester  
>> so you can still happily add any wierd/wacky rules you want. Also for  
>> doing simple property / XML changes there's a little .betwixt mapping  
>> XML file you can do this with. Though I doubt we'll need to worry  
>> about that - we can just code the beans right (so they use the same  
>> property names as the XML elements/attributes).
> That is my exact problem... In this case the beans are required by the  
> JMX specification and they got the naming wrong.

Which beans are we talking about? I've been talking about the 7 XSD  
schemas. Are you talking about something else? You're not off in MLET  
land or something are you?

> The JMX spec tries to reuse a base class for MBeanAttributeInfo,  
> MBeanOperationInfo and MBeanNotificationInfo.  They all have a field  
> called name, which makes since for attribute an operation, but for  
> notification the spec says that name caries the java type of the  
> notification object.  The over user of inheritance here has caused the  
> property to have the wrong name.  In the xml I rename the property to  
> name as it is easier for out users to understand.
> My guess is there will be a ton of special mappings for the j2ee specs  
> as the descriptors tend to be poorly designed.

I don't follow. e.g. in ejb-jar or web.xml what are the issues? I  
thought we were talking about beans to represent the 7 XSD schemas in  

>>>> Also note that Digester is read only - it cannot generate XML.  
>>>> Betwixt defaults digester rules to parse XML and can generate XML  
>>>> from the beans if required.
>>> Cool.  Can Digester do this or does digester do something special to  
>>> make it happen?
>> No. Thats what betwixt is for - its the other half of digester  - to  
>> allow beans to generate XML - and as an automatic way of generating  
>> digester rules from  beans which use getter / setter and adder >  
>> methods.
> Yes, but how does it do it.

Betwixt just makes a normal Digester - it is-a digester - it defaults  
the Rules in Digester from a bean introspection defaults via the  
So there's nothing taken away - you can still add custom digester rules  
yourself by hand.

> Is it building a reverse digester using Digester or does it have it's  
> own logic that knows how to do it?  I like that feature, but not the  
> rest of Betwixt.

There is no digester feature to output XML. So the output of XML is a  
purely betwixt thing. Basically Betwixt creates a little XMLBeanInfo  
class which describes how to map it to XML and this is used to go XML  
-> bean (defaulting digester rules) and to go bean -> XML.


View raw message