So +1 from me :) My schedule is tight and more complex cases can be documented as a current limitation.
> -----Original Message----- > From: Anthony Elder [mailto:[EMAIL PROTECTED]] > Sent: Thursday, February 20, 2003 8:41 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]] > > > > 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 > > > >
