axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Amila Suriarachchi" <amilasuriarach...@gmail.com>
Subject Re: AXIS2 - Sad State of code generation tools?
Date Wed, 16 Apr 2008 05:09:40 GMT
On Wed, Apr 16, 2008 at 6:32 AM, Dan Armbrust <
daniel.armbrust.list@gmail.com> wrote:

> > > 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.
>
> With exceptions, it seems to be taking things one step farther than
> the ADB bean.
>
> So, I start with an interface like this:
>
> String[] getSupportedMatchAlgorithms () throws
> org.hl7.CTSVAPI.UnexpectedError;
>
> I feed this into Java -> WSDL, and then WSDL -> Java, and I get a
> server Skeleton with the following signature:
>
> public org.hl7.CTSVAPI.GetSupportedMatchAlgorithmsResponse
> getSupportedMatchAlgorithms()
>        throws UnexpectedErrorException0;
>
> Thats just not the same at all.  My implementation code shouldn't have
> to know anything about these new classes that have appeared -
> GetSupportedMatchAlgorithmsResponse and UnexpectedErrorException0.
>
> So, I turn on the "unwrap" flag "-uw" on the wsdl2java tool - and then
> I get this signature in my server skeleton class:
>
>    public java.lang.String[] getSupportedMatchAlgorithms()
>        throws UnexpectedErrorException0;
>
> So, now the return data type is all good.  But the throws clause is
> still a new made up class, as far as I'm concerned.  That wasn't in
> the API I fed in, so there should be a way for me to generate code
> that has the same signature when it comes back out.
>
> Especially when the implementation of the UnexpectedErrorException0
> class does nothing more than wrap the class "UnexpectedError10" with
> getters and setters and a private instance variable.  The
> UnexpectedError10 class contains all of the ADB bean stuff.


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.


>
> FYI - here is the command I'm using to go from wsdl to java (in ant
> exec syntax).
> <arg line="-o ${wsdl.java.target.dir}" />
> <arg line="-ns2p a bunch of stuff.../>
> <arg line="-ss"/>
> <arg line="-sd"/>
> <arg line="-ssi"/>
> <arg line="-f"/>
> <arg line="-uw"/>
> <arg line="-uri ${wsdl.target.dir}/${wsdlSource}.wsdl" />
>
>
> > > 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.
> >
>
> Hmm.  I'm not sure I'm following correctly.  When I generated the
> WSDL, the java code that I fed in has a single instance of the
> exception.  Its one class.  When it comes back out the other side, I
> have 2 instances of this class  Plus a class which simply wraps
> another class, as described above, around one of them.  Something
> clearly seems broken to me.  But I don't know enough about what a WSDL
> file is supposed to look like to be sure if it is being messed up
> during the Java -> WSDL stage, or if it happens during the WSDL ->
> Java stage.


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.


>
> In Axis1 - when I feed one exception in one side, I get one exception
> back out the other side.
>
> > > 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,
Amila.

>
>
> To be clear, I'm talking about signatures like this:
>
> WSDL:
>            <xs:element name="lookupCodeExpansion">
>                 <xs:complexType>
>                    <xs:sequence>
>                        <xs:element minOccurs="0"
> name="expandConcept_id" nillable="true" type="ns1:ConceptId"/>
>                        <xs:element minOccurs="0"
> name="relationship_code" nillable="true" type="xs:string"/>
>                        <xs:element minOccurs="0"
> name="sourceToTarget" type="xs:boolean"/>
>                        <xs:element minOccurs="0"
> name="directRelationsOnly" type="xs:boolean"/>
>                        <xs:element minOccurs="0"
> name="designationLanguage_code" nillable="true" type="xs:string"/>
>                        <xs:element minOccurs="0" name="timeout"
> type="xs:int"/>
>                        <xs:element minOccurs="0" name="sizeLimit"
> type="xs:int"/>
>                     </xs:sequence>
>                </xs:complexType>
>            </xs:element>
>
>
> Java from WSDL:
>
>    public org.hl7.CTSVAPI.RelatedCode[] lookupCodeExpansion(
>        org.hl7.CTSVAPI.ConceptId expandConcept_id,
>        java.lang.String relationship_code, boolean sourceToTarget,
>        boolean directRelationsOnly, java.lang.String
> designationLanguage_code,
>        int timeout2, int sizeLimit3)
>        throws UnknownLanguageCodeException1,
> UnknownRelationshipCodeException6,
>            UnknownConceptCodeException4, UnknownCodeSystemException5,
>            TimeoutErrorException7, UnexpectedErrorException0;
>
> timeout2?  sizeLimit3?  Those just shouldn't be changed.
>
>
>
> > 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.
>
> That fine, I don't expect it to be identical.  Axis1 wasn't identical,
> but it was pretty close.  But the way that Axis2 is treating
> exceptions vastly changes the API.  I don't care what happens behind
> the scenes - but the class names and publicly visible methods should
> be the same.
>
> > 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).
>
> Well, no, but these issues that I consider bugs haven't been
> confidence inspiring.  And if I can't take a client-server
> architecture, and put Axis2 in the middle without spending a week
> making the client and server compile against the stubs because all the
> signatures changed (and would likely change again with the next
> release of Axis2) - well, I just can't support that.  Especially when
> I know Axis1 works without mauling the signatures and exception class
> names.
>
> All of the above examples were done with the 1.3 release of Axis2.
> I'll try the nightly build, and see what changes.
>
> Thanks,
>
> Dan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>


-- 
Amila Suriarachchi,
WSO2 Inc.

Mime
View raw message