ws-wsif-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <gdani...@macromedia.com>
Subject RE: [wsif] generic type mapping [Re: bug 16485 [BeanDeserializer error when XML element starts with a capital letter]]
Date Thu, 20 Feb 2003 13:05:43 GMT

Hi ant!

I know that this is a particular case that you want to get working, but I don't think the
workaround is the right thing.

First off, you can have bean fields which start with a capital letter and preserve correct
casing.  In particular, if the second character is capitalized also:

    String FOO;
    public String getFOO()...
    public void setFOO(String)...

The bean property here will be "FOO", not "fOO".  (this is tricky and took us a while to get
right)

I agree with Nirmal that although this might take care of this problem in many cases today,
it's just a band-aid and can't deal with many other situations which might come up tomorrow.
 For instance, what if the XML for a field is any of these:

    <foo-bar>  (which turns into FooBar)
    <_foo_>    (which turns into _Foo_)
    <foo attributeField="bar">   (which has an attribute)

Like I said before, metadata here is not an option, it's a requirement.

1. Your patch works fine for deserializing.  OK, what about serializing?  Let's say you're
calling an "echo" service; you would have no way of knowing that the XML should have the first
letter uppercased, so you'd send "<name>", right?  The service on the other side would
have every right to fault at that point since you sent a non-valid message according to the
schema.  Does .NET actually ignore case when reading XML?  (even if it does, that's a bug)

2. Let's say you have the valid but misguided schema:

    <element name="Name" type="xsd:string"/>
    <element name="name" type="xsd:int"/>

   and then you get the following XML:

    <Name>forty-two!</Name>

   First of all, I don't know what the bean-generator you're using would do here.  Second,
I'm certain that your patch wouldn't handle this situation.

3. Use any of the examples above (<foo-bar>, etc) in a schema and generate beans with
your favorite technology.  Either they a) won't work, or b) (more likely) have metadata somewhere.
 GLUE puts it in an annotated xsd file (a very cool trick).  .NET puts it in the class itself
as attributes ([XmlAttribute], etc).  Axis uses TypeDescs.  If you hope to use one of these
types of beans with another type of system, you need to transfer not just the code, but the
metadata as well.

I'm sorry, I know it's a pain, but if you're dealing with XML you have to respect the rules
of XML, not try to make it conform to Java.

--Glen

> -----Original Message-----
> From: Anthony Elder [mailto:ant.elder@uk.ibm.com]
> Sent: Thursday, February 20, 2003 7:36 AM
> To: wsif-dev@ws.apache.org; axis-dev@ws.apache.org
> Subject: RE: [wsif] generic type mapping [Re: bug 16485
> [BeanDeserializer error when XML element starts with a 
> capital letter]]
> 
> 
> 
> I think there may be some misunderstanding about this problem.
> 
> If you have a Java bean with a field
> 
>       String xyz;   // <-- starts with lowercase
> 
> then Java conventions say there will be methods getXyz() and setXyz().
> 
> If you change the field name to be:
> 
>       String Xyz;   // <-- starts with uppercase
> 
> then Java conventions say there will be methods getXyz() and 
> setXyz(). Note
> the methods have identical names in both examples.
> 
> The BeanSerializer uses the names of the methods to find what an XML
> element will map to. setXyz() is assumed to mean that there is a field
> named xyz, which maps to an element named xyz. But this 
> assumption is wrong
> in the second example, and if there is an element named Xyz 
> there is *no
> way* in Java to differentiate the getter and setter methods.
> 
> What this means is that currently it is *impossible* to use a 
> simple bean
> without TypeDesc info with a schema where an element name 
> starts with a
> capital letter.
> 
> There wont be a new case tomorrow where we need a new patch 
> to understand
> some other character as this is the one single only very 
> specific situation
> where it doesn't work.
> 
> Lets wait and see what Glen thinks about the new patch, to me 
> it seems by
> far the cleanest solution.
> 
>         ...ant

Mime
View raw message