axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Armbrust" <daniel.armbrust.l...@gmail.com>
Subject Re: AXIS2 - Sad State of code generation tools?
Date Thu, 17 Apr 2008 22:56:07 GMT
> 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: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org


Mime
View raw message