Hi Chuck, Oops a daisy, We've significantly changed the de-serializing code and the de-ser code is not simple anymore (the previous de-ser code was buggy anyway). I'm in the process of fixing it further but right now it handles only sequences. I'll incorporate the changes needed for the choice and all soon. Thanks for the fix anyway.
On 2/9/06, Chuck Williams <[EMAIL PROTECTED]> wrote: > Ajith, > > Thre was another problem in the patch I submitted to handle <choice>: the > generated adb bean parse() methods used an incorrect value for the > argumentCount. They assumed all arguments were required, rather than > precisely 1. Fixing this required one more simple change to > ADBBeanTemplate.xsl. The updated version of the complete patch (relative to > 0.94 release) is attached. > > Chuck > > > > Chuck Williams <[EMAIL PROTECTED]> wrote on 01/26/2006 08:23:24 AM: > > > > Hi Ajith > > I think the validation is a good idea, but the issues I listed below all > generated NullPointerException's on valid wsdl. I have been validating the > wsdl with my ide (Netbeans) prior to submitting it to the code generator. > That did help to diagnose some problems, but not all. The code generator > has many constraints that go beyond validation (e.g., names in many places > they are not required due to the way the data structures work, valid > references of course, and one I don't understand yet: messages with > multiple parts are only supported if the part constraints are type=, not if > they are element=). > > Thanks, > > Chuck > > > > Ajith Ranabahu <[EMAIL PROTECTED]> wrote on 01/26/2006 03:13:00 AM: > > > Hi Chuck, > Thanks for pointing out the issues. > Yes, the code generator being non-validating is the problem here. We do > not check whether the WSDL is valid before attempting to generate code. IMHO > I think we should have a WOM validator as one of the extensions in the > codegenerator - the user can switch off validation if needed. > My guess is if we have the WSDL validator then we may overcome a number of > issues > > > On 1/26/06, Chuck Williams < [EMAIL PROTECTED]> wrote: > > Ajith, > > > > You probably already saw the second issue in the xsl (an unintended side > effect on optional and array-valued properties). Just in case you didn't > notice > > that one, please see the difference in the new version of the patch (still > against 0.94). I've now created and generated code for a large wsdl and so > have growing confidence in the patch. > > > > The biggest issue I've seen in using the code generator is the lack of > error detection. E.g., missing name attributes where axis2 expects them > (even if > > they are not required by the wsdl spec), multiple parts in messages that > take elements rather than types (element= as opposed to type=), typos in > certain references, all generally yield NullPointerException. With a large > wsdl especially, the problems can be a challenge to find. Are there plans > > to beef up the error checking? > > > > Thanks, > > > > Chuck > > > > > > > > Chuck Williams <[EMAIL PROTECTED]> wrote on 01/24/2006 09:17:14 PM: > > > > > > > > Ajith, thanks again! Very nice of you to not embarass me on the list, > although I managed to do that myself pretty well. :-) > > > > For the benefit of others using 0.94, the corrected patch is attached to > this message. I also updated the bean schema for completeness, although it > appears it is missing a couple other attributes as well so probably not > important. > > > > Chuck > > > > > > > > Ajith Ranabahu <[EMAIL PROTECTED]> wrote on 01/24/2006 09:04:56 PM: > > > > > > Well Actualy when I went through the patch I figured out the mistake:) > It's already corrected :) > > > > > > On 1/25/06, Chuck Williams < [EMAIL PROTECTED]> wrote: > > > Thanks Ajith! Unfortunately, I need to send you a revised version. > There is a stupid mistake in my xsl that broke the other types! I had only > verified that the <choice> code worked, not yet verified that the rest of > the generated code wasn't affected. It's a trivial change I'm testing now, > so should be just few. Mea culpa -- sorry for the confusion. > > > > > > Regarding the code, it is very easy to read. I compliment you on the > organizaiton. > > > > > > Chuck > > > > > > > > > > > > Ajith Ranabahu <[EMAIL PROTECTED]> wrote on 01/24/2006 08:52:44 > PM: > > > > > > > > > > > > Hi Chuck, > > > I looked at your solution and it is reasonable for handling choice. I > applied the patch (Actually modified the classes looking at the patch. > TortoiseSVN throws an exception when I try to apply the given patch) > > > Thanks a lot for your effort in participating in the development effort. > We really appreciate you coming forward and solving this issue. I've already > solved the ref issue. > > > > > > BTW you seem to have understood the workings of the code well. Did it > take a lot of effort to figure out the stuff ? > > > > > > > > > > > > On 1/25/06, Chuck Williams <[EMAIL PROTECTED] > wrote: > > > > Dims and Ajith, > > > > > > > > I took Dims' advice and created the attached patch to > modules/codegen/src of Axis2 0.94. This may not be the best implementation > of <choice> but it is very simple and meets my use cases. The idea is this. > A <choice> is treated just like an <all> where each enclosed element has > minOccurs=0, except that in the generated code setting any constituent > element automatically unsets all the others. Thus, whatever choice you set > last is the choice you get and you only get one. (The code does not enforce > what happens if you don't set any; this, additional error checking, and > accessors to fully determine the state of what has been chosen, could all be > improved.) > > > > > > > > I'm just starting to work with it so have not tested it much yet, but > the generated code looks right to me. It's very simple because it reuses > all the code that is already there and makes just a few mods. > > > > > > > > I haven't tried complex nesting cases to see if they all work, and > probably wont' because I only need <choice> of <element>'s, although in > principle any nesting that <all> handles, choice should too. > > > > > > > > I noticed in doing this that none of the particles handle the <element > ref=...> construction. This is somewhat painful, but livable. If I had > more time, I'd try to fix that. It looks like it might be more complex than > this hack due to the way the names are used in the data structures. > > > > > > > > I'd appreciate if you guys would add this to axis2 so I don't have to > patch future releases. If it is not deemed suitable, please let me know why > as perhaps I could fix it, or just fix it! > > > > > > > > Thanks, > > > > > > > > Chuck > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Ajith Ranabahu > > > > > > > > > > > -- > > Ajith Ranabahu > > > > > > > > > > -- > Ajith Ranabahu > > > -- Ajith Ranabahu
