> > 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.
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.
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.
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
