On Mon, Apr 14, 2008 at 2:31 AM, Dan Armbrust < [EMAIL PROTECTED]> 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 exception? For exceptions it adds an local ADB bean to exception class to generate the element define in the WSDL fault element. > > UnexpectedError.java > UnexpectedError5.java > UnexpectedError5Exception.java > > 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 wsdl. 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Amila Suriarachchi, WSO2 Inc.
