+1
A better solution can be investigated for the future, to cover the bigger
issue.
Owen
|---------+---------------------------->
| | Anthony |
| | Elder/UK/IBM@IBMG|
| | B |
| | |
| | 20/02/2003 13:41 |
| | Please respond to|
| | wsif-dev |
| | |
|---------+---------------------------->
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED], [EMAIL PROTECTED]
|
| cc:
|
| Subject: RE: [wsif] generic type mapping [Re: bug 16485 [BeanDeserializer
error when XML element starts with a capital |
| letter]]
|
|
|
|
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
Yipee, go Glen, +1 from me!
You're right it doesn't solve all the possible problems, but it does solve
this particular problem fine, and from the perspective of WSIF seemlessly
interoperating with .Net type services I think this is the right thing to
do now.
If someone is already using some other SOAP API on their client and they
have Java beans generated with whatever metadata that SOAP implementation
uses, then to try using WSIF they have to generate a whole lot of new
beans. This fix enables WSIF to work with their existing classes in the
majority of cases which makes it much easier for them to try out WSIF.
It doesn't mean we can't continued to work on the other more comprehensive
solutions.
If you're still listening Jacques-Olivier feel free to vote to show your
support even though you're not a committer.
...ant
Anthony Elder
[EMAIL PROTECTED]
Web Services Development
IBM UK Laboratories, Hursley Park
(+44) 01962 818320, x248320, MP208.
Glen Daniels <[EMAIL PROTECTED]> on 20/02/2003 13:14:52
Please respond to [EMAIL PROTECTED]
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>,
[EMAIL PROTECTED]
cc:
Subject: RE: [wsif] generic type mapping [Re: bug 16485
[BeanDeserializer error when XML element starts with a
capital letter]]
Hi ant:
> The problem with option 2 is that its WSDL driven, but the
> WSIF client may
> not have control over the WSDL, so WSIF still wont work with
> all that .Net
> WSDL with the capital letters.
I still don't get this. If you're generating your JavaBeans from WSDL, you
have, guaranteed, the right schema information (unless the WSDL is bad!).
That's all you need to generate the required metadata so you can happily
serialize and deserialize all day (doo dah, doo dah...). Maybe I
misunderstood option 2 - I'd thought you meant programatically, not by
adding information to the WSDL.
> So I think added to the original list of options should be:
>
> 4 - design a WSIF specific way to add the required metadata
> info to the
> bean class and get the WSIF AXIS provider to somehow get that
> from the bean
> and tell the AXIS BeanDeserializer about it.
>
> For this metadata perhaps we could create new WSIF classes
> called TypeDesc
> and Field and a WSIF schema tool that creates beans from a
> schema which
> include a static TypeDesc field initialised with the required
> metadata.
> AXIS has already done that so we could just nick the existing
> AXIS classes
> and change axis to wsif in their package name. ;)
Or we could start moving forward at an attempt to merge the two projects
into one....
> I'd dispute the claim that "patching that to solve one
> problem will not
> help" - yes it will help, tolerating variations in the case of the 1st
> character fixes this particular problem completely.
Tell you what. I'm OK with putting in the patch IF a) we don't make this
the default behavior, but have a configuration switch which turns it on
("laxDeserialization" or something), and b) the other committers vote +1 on
it. Putting it in will perhaps solve this particular problem (though I
still don't understand how you could possibly deal with xml like <foo-bar>
or with attributes), but it will cause situations that were working before
in Axis to break (both "name" and "Name").
--Glen
