axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Amila Suriarachchi" <>
Subject Re: AXIS2 - Sad State of code generation tools?
Date Tue, 15 Apr 2008 03:37:38 GMT
On Mon, Apr 14, 2008 at 2:31 AM, Dan Armbrust <> wrote:

> I have come into Axis2, trying to bring some  older code up to date
> that was first done with Axis 1.
> My master API is written as IDL.  In Axis1, the path that was taken
> was IDL -> Java -> WSDL -> Java -> Implement these stubs.
> While not straightforward, this did work, without any major issues.
> Now, I get a 1.3 version of Axis 2, to try to "upgrade" my code - and
> I'm left with the distinct feeling that the code generation tools in
> Axis2 aren't yet worthy of a 1.0 release number.
> (I'm not looking to step on any toes... please don't take it the wrong
> way - it's entirely possible I'm misusing the tools - so if there
> things I can do to address the following issues, please correct me -
> but it just seems like things aren't close to ready for primetime yet)
> 1)  When I go from Java -> WSDL, the tools refuse to follow my
> submitted namespace for exceptions and return types.  Instead, it
> invents new namespaces for the exceptions and return types when it
> creates the WSDL.
> 2)  Java -> WSDL  doesn't handle superclasses.
> So, I manually hack the WSDL a bit to clean up the namespaces - and
> proceed to run the WSDL -> Java step.
> 3)  The Java -> WSDL refuses to "unwrap" the exceptions.  It always
> does a pattern like this:

The unwrapping is only applied to input and output parameters. What do you
mean by unwrapping an
For exceptions it adds an local ADB bean to exception class to generate the
element define in the
WSDL fault element.

> And then it uses the UnexpectedError5Exception class in my exposed web
> methods.  I don't understand where the "5" version of the class comes
> from - It doesn't make sense.

Here the problem this that you have an element, complex type and a fault
message in the same namespace. Since it can not use the same name for three
classes it adds a suffix. Try with a nightly build. Element class is
generated with the suffix E.

> 4)  WSDL -> Java is appending random numbers to the end of all of my
> primitive variable names in the methods.

This is a mechanism to prevent compilation errors.

> So, it seems that I'm stuck.  These interfaces are too large to be
> handcrafting this code.  I could probably write scripts that could
> automatically fix the issues with the generated WSDL, but then
> signatures for the server side stubs that I generate from the WSDL are
> way off from what was specified in the IDL, mostly due to the
> Exception unwrapping issues.

First of all if you generate the wsdl from the java classes and regenerate
the skelton there is no guarantee
to have the same method signature. Since wsdl2java tool knows only  the wsdl
you feed to it.
It does not know anything about the  java class it used to generate the
If you go through the code you can see it has generated some special classes
called ADB classes to handle input and output request and those things can
never be in the original code.

> Even if I were to dive in, and try to fix all of these issues in the
> code generators, I sure haven't gotten much confidence that Axis2 will
> work properly at runtime, given all of the issues I've had so far.

All your problems related to the class names and parameter names. As you can
see this does not
have any problem with the generated code. (in technical point of view).

> And now I see that you are pushing toward a 1.4 release, while there
> are still 31 "critical" bugs open when I search on wsdl.  Many of
> which probably cover and/or overlap the issues I have described here.
> Are these issues just not on anyone's radar, or priority list?
> Is the rest of Axis2 in better shape than this - does it work for
> folks with real world apps?  Or should I just go back to Axis1?
> Thanks,
> Dan
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Amila Suriarachchi,
WSO2 Inc.

View raw message