> The fault element of the wsdl looks like this. > > <xs:element name="UnexpectedError"> > > <xs:complexType> > <xs:sequence> > <xs:element minOccurs="0" > > name="UnexpectedError" nillable="true" type="ns0:UnexpectedError"/> > > </xs:sequence> > </xs:complexType> > </xs:element > > > <xs:complexType name="UnexpectedError"> > <xs:complexContent> > <xs:extension base="ns0:Exception"> > > <xs:sequence> > <xs:element minOccurs="0" > > name="possible_cause" nillable="true" type="xs:string"/> > </xs:sequence> > </xs:extension> > </xs:complexContent> > </xs:complexType> > > So an error occurs service has to send a soap:fault element of which > 'detail' element should have an > xml element as defined above. So we need to have an ADB class inside the > exception class. So if you can edit your element some thing similar to this, > > <xs:element name="UnexpectedError"> > > <xs:complexType> > <xs:sequence> > <xs:element minOccurs="0" > name="possible_cause" nillable="true" type="xs:string"/> > </xs:complexType> > </xs:element> > > it has a less over head.
So your saying, the problem (from my perspective) that the Exceptions are getting wrapped up inside of other classes is happening in the java -> WSDL step - so that is the tool that is broken here. :) Editing anything is pretty much out of the question here, based on the sheer volume of types that are messed up in my code base. Writing a script to fix this level of problem would take me a while, so fixing the java -> wsdl converter would probably be a better use of my time. But I don't think my current project deadlines are going to allows that at the moment, especially since Axis1 doesn't have this issue. > > Here you have this element and complex type > <xs:element name="UnexpectedError"> > > <xs:complexType> > <xs:sequence> > <xs:element minOccurs="0" > > name="UnexpectedError" nillable="true" type="ns0:UnexpectedError"/> > > </xs:sequence> > </xs:complexType> > </xs:element > > > <xs:complexType name="UnexpectedError"> > <xs:complexContent> > <xs:extension base="ns0:Exception"> > > <xs:sequence> > <xs:element minOccurs="0" > > name="possible_cause" nillable="true" type="xs:string"/> > </xs:sequence> > </xs:extension> > </xs:complexContent> > </xs:complexType> > > both have the UnexpectedError with same package name. therefore ADB appends > an suffix (number) to make class name unique. In truk it generates a suffex > E for element. > Again, this was also done by the java -> wsdl step. So another regression, as far am I'm concerned, from Axis1. > > > > 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, by mechanism, do you mean hack, to fix some other issue inside the > > code generator? Because I really don't think it should be changing > > the names of my variables. > > This is a precaution to prevent compilation error it adds this number > suffix. I'll try to give an option not to generate this suffix. Thanks for looking into it - but for my own curiosity, why would you make this an option? When is there a use case when you would want it to read variable names from a wsdl file, and randomly append numbers to them? Maybe it's a cross language issue, that I'm not thinking of, since I'm thinking java here. In any case, it seems better to only append numbers if there actually is a collision. Since most of my issues have been narrowed down to the java -> wsdl converter - I could probably do it by using the java -> wsdl converter from Axis1, and using Axis2 from there. But then I wonder, what would the WSDL look like when I ask the Axis2 server for the service WSDL? I mean, it has to generate that, doesn't it? Doesn't it do that using the same code as the java -> wsdl converter? So any client of my service would have the same problems - when they generate their client stubs, all of the API's would be vastly different than what I think they should have. Oh, and I did try rerunning everything with a daily build - there wasn't any major improvements of consequence for my issues. Should I file bugs on these java -> wsdl converter issues? Or is it a design decision that Axis2 tooling won't support maintaining API sanity when you take java code on a round trip through it? Thanks for the help, Dan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
