Re: [Axis2-0.94] WSDL2Java generates bad code for complex types

[Chuck Williams]

Hi Jeff, I guess I shoudln't be too surprised that you are on this list, but you did catch me off guard!  Hope you are well. You are right of course, but it turns out the patch actually does what you say, more or less, due to the way Axis2 works (at least as the code appears to me).  It treats <sequence> and <all> in the same manner except that <sequence> requires and ensures the specified ordering.  I haven't tried the nested cases; it either doesn't work for <sequence> or is too liberal for <all>, or some of both (my guess).  All 3 particles are processed by the same method, with the only difference being whether the ordering is enforced (sequence) or whether only one value is accepted (choice). Thanks for pointing out the constraints on <all>, Chuck Jeff Greif <[EMAIL PROTECTED]> wrote on 01/24/2006 08:44:33 PM: Hi Chuck, Just as a point of information, <all> itself can only have maxOccurs=1 and minOccurs=(0,1}, each of its particles has the same restriction, and all the particles must be <element>. No nested sequence, choice or all is allowed. The main reason for the restrictions, I think, is that XML Schema requires deterministic parsing with no lookahead. While I'm not familiiar with the code you patched, it might have captured more of the semantics of choice to base the patch on the treatment of <sequence> rather than <all>, initially applying a similar trick to the one you described, and eventually properly rejecting cases where more than one branch appeared. The same degree of code reuse may be possible in that approach. Jeff On 1/24/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.