commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian K. Wallace" <>
Subject Re: [betwixt] Object and Array handling
Date Tue, 15 Apr 2003 22:38:21 GMT
<snipped the default constructor section - it'd be nice, but if it's not a bean, it's not

> >   1.  If an array of an object is passed in to the BeanWriter's write 
> > method, the
> > resulting XML isn't valid (the root object ends with a semicolon). e.g., 
> > a String[]
> > passed to the write method writes the String objects properly, but 
> > enclosed in a
> > <String;> element - which causes a SAXParseException (whitespace required

> > before
> > attribute).
> this is a betwixt bug. i've just committed a fix for this.
Thank goodness. :-)

> >   2.  If a method in a bean takes a java.lang.Object as a parameter, the 
> > XML written
> > out by the BeanWriter writes the object correctly (although it should 
> > probably encase
> > the written object in an element of the object's correct type),
> i'm not sure about this. betwixt isn't really concerned with serialization 
> but with automating common mapping use cases. i'd be happier to think 
> about adding a setting that allowed classname to be written as an 
> attribute rather than as an element. i don't know if that would be any use 
> to you.
I looked at manually writing the classname via the 'className' attribute, but this isn't 
really what I think should be done - as you said, betwixt isn't really concerned with 
serialization - which makes it much more open to sharing the XML with non-Java 
entities - to which className would mean nothing. What I was thinking about was an 
option (?) to specify writing the object out with the object type as an element 
surrounding the actual contents of the object. Given the following bean description:
public class Person {
  public void setExtrainfo(Object[] iValue) {
  public Object[] getExtrainfo() {
  public void addExtrainfo(Object iValue) {
where the 'Extrainfo' is an "image" and a "greeting" (may not be the best example... 
but hey)
to produce the following XML:
or even this XML minus the "<object>" and "</object>" surrounding the image and

greeting elements.

In this case, there's no mention of classes, no need to be able to re-create the exact 
bean used to write the XML. As long as the 'reader' knows what to do with a 'person', 
'image', and 'greeting', and can set the 'persons' extrainfo accordingly.

> > but the BeanReader
> > does not create an object of the orginal type to pass to the set method. 
> > What is put
> > into the bean after a read is an actual java.lang.Object.
> betwixt guesses the type of object to create by examining the type of the 
> parameter. so, if the method takes an object, this is what will be created.
>   one way that this could be partially address is by adding a attribute in 
> the betwixt file that allows the concrete class to be created to be 
> specified. (this is needed to support interfaces.) i'm not sure whether 
> this would be of any use to you.
This issue (for me) actually arose from trying to read in XML formatted in the manner 
described above. I'm not looking to change the way the reader creates its beans - 
register a concrete class for an element and be done with it.  What is of concern is 
(given the XML above) if I have a 'person', 'image', and 'greeting' registered with the 
reader, all these beans get created properly (from what I've been able to deduce) - 
the problem is that the rule for setting /person/extrainfo is /object. I'd view the reading

to be much more robust if it would attempt an exact match - but failing that, look at 
inheritance. Is what I created for an 'image' an instance of an Object? it is? then add 
it to the extrainfo. I'd think that failing an exact match, utilizing some sort of "instance

of" or "assignable from" should allow the already created 'image' bean to be 'set' in 
the person's extrainfo - instead of looking only at the setExtrainfo method and seeing 
that it takes an object.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message