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
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
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
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
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
|
