On Fri, Apr 18, 2008 at 4:26 AM, Dan Armbrust < [EMAIL PROTECTED]> wrote:
> > 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? it shows the wsdl you gave to generate the code. i.e Axis1 generated code for this case. > > 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? please log a jira. thanks, Amila. > > > > Thanks for the help, > > Dan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Amila Suriarachchi, WSO2 Inc.
