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:[EMAIL PROTECTED]]
> Sent: Thursday, February 20, 2003 7:36 AM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> 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
