You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Dan Armbrust <da...@gmail.com> on 2008/04/13 23:01:26 UTC
AXIS2 - Sad State of code generation tools?
I have come into Axis2, trying to bring some older code up to date
that was first done with Axis 1.
My master API is written as IDL. In Axis1, the path that was taken
was IDL -> Java -> WSDL -> Java -> Implement these stubs.
While not straightforward, this did work, without any major issues.
Now, I get a 1.3 version of Axis 2, to try to "upgrade" my code - and
I'm left with the distinct feeling that the code generation tools in
Axis2 aren't yet worthy of a 1.0 release number.
(I'm not looking to step on any toes... please don't take it the wrong
way - it's entirely possible I'm misusing the tools - so if there
things I can do to address the following issues, please correct me -
but it just seems like things aren't close to ready for primetime yet)
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:
UnexpectedError.java
UnexpectedError5.java
UnexpectedError5Exception.java
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.
4) WSDL -> Java is appending random numbers to the end of all of my
primitive variable names in the methods.
So, it seems that I'm stuck. These interfaces are too large to be
handcrafting this code. I could probably write scripts that could
automatically fix the issues with the generated WSDL, but then
signatures for the server side stubs that I generate from the WSDL are
way off from what was specified in the IDL, mostly due to the
Exception unwrapping issues.
Even if I were to dive in, and try to fix all of these issues in the
code generators, I sure haven't gotten much confidence that Axis2 will
work properly at runtime, given all of the issues I've had so far.
And now I see that you are pushing toward a 1.4 release, while there
are still 31 "critical" bugs open when I search on wsdl. Many of
which probably cover and/or overlap the issues I have described here.
Are these issues just not on anyone's radar, or priority list?
Is the rest of Axis2 in better shape than this - does it work for
folks with real world apps? Or should I just go back to Axis1?
Thanks,
Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: AXIS2 - Sad State of code generation tools?
Posted by Paul Fremantle <pz...@gmail.com>.
Dan
I haven't looked at your problems in detail, but I wanted to add this
in case it helps:
You could start from your existing (Axis1 J2W generated) WSDL and just
go from their. Java->WSDL behaviour is not necessarily specific to any
toolkit.
Paul
On Sun, Apr 13, 2008 at 10:01 PM, Dan Armbrust
<da...@gmail.com> wrote:
> I have come into Axis2, trying to bring some older code up to date
> that was first done with Axis 1.
>
> My master API is written as IDL. In Axis1, the path that was taken
> was IDL -> Java -> WSDL -> Java -> Implement these stubs.
>
> While not straightforward, this did work, without any major issues.
>
> Now, I get a 1.3 version of Axis 2, to try to "upgrade" my code - and
> I'm left with the distinct feeling that the code generation tools in
> Axis2 aren't yet worthy of a 1.0 release number.
>
> (I'm not looking to step on any toes... please don't take it the wrong
> way - it's entirely possible I'm misusing the tools - so if there
> things I can do to address the following issues, please correct me -
> but it just seems like things aren't close to ready for primetime yet)
>
> 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:
> UnexpectedError.java
> UnexpectedError5.java
> UnexpectedError5Exception.java
>
> 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.
>
> 4) WSDL -> Java is appending random numbers to the end of all of my
> primitive variable names in the methods.
>
> So, it seems that I'm stuck. These interfaces are too large to be
> handcrafting this code. I could probably write scripts that could
> automatically fix the issues with the generated WSDL, but then
> signatures for the server side stubs that I generate from the WSDL are
> way off from what was specified in the IDL, mostly due to the
> Exception unwrapping issues.
>
> Even if I were to dive in, and try to fix all of these issues in the
> code generators, I sure haven't gotten much confidence that Axis2 will
> work properly at runtime, given all of the issues I've had so far.
>
> And now I see that you are pushing toward a 1.4 release, while there
> are still 31 "critical" bugs open when I search on wsdl. Many of
> which probably cover and/or overlap the issues I have described here.
>
> Are these issues just not on anyone's radar, or priority list?
>
> Is the rest of Axis2 in better shape than this - does it work for
> folks with real world apps? Or should I just go back to Axis1?
>
> Thanks,
>
> Dan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
--
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: AXIS2 - Sad State of code generation tools?
Posted by Amila Suriarachchi <am...@gmail.com>.
On Fri, Apr 18, 2008 at 4:26 AM, Dan Armbrust <
daniel.armbrust.list@gmail.com> 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: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
--
Amila Suriarachchi,
WSO2 Inc.
Re: AXIS2 - Sad State of code generation tools?
Posted by Dan Armbrust <da...@gmail.com>.
> 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
Re: AXIS2 - Sad State of code generation tools?
Posted by Amila Suriarachchi <am...@gmail.com>.
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.
Re: AXIS2 - Sad State of code generation tools?
Posted by Dan Armbrust <da...@gmail.com>.
> > 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: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
AXIS2 - Sad State of code generation tools?
Posted by Dan Armbrust <da...@gmail.com>.
> Can you send the wsdl files generated by both Axis1 and Axis2?
>
> thanks,
> Amila.
>
And the second file - attached (hopefully - if the mail list manager likes me)
AXIS2 - Sad State of code generation tools?
Posted by Dan Armbrust <da...@gmail.com>.
> Can you send the wsdl files generated by both Axis1 and Axis2?
>
> thanks,
> Amila.
>
(try 2 - one attachment at a time)
Attached. Things to note: In the Axis2 file, the namespace
"xmlns:ns1="http://CTSVAPI.hl7.org/xsd" was invented by the java ->
wsdl tool.
The all of my classes are supposed to be in is
"xmlns:ns0="urn://hl7.org/CTSVAPI". I think that this, in and of
itself is the source of a lot of my issues.
When I take that into account, and manually merge the two schemas
together, things get a little better later in the generation process.
The Axis1 WSDL was generated with these flag (pretend all of these ant
variables are populated with something reasonable):
<arg line="-o ${wsdl.target.dir}/${wsdlTarget}.wsdl" />
<arg line="-n ${wsdlUrn}" />
<arg
line="-lhttp://localhost:8080/axis/services/${wsdlTarget}Service" />
<arg line="-p${v3dt.package}=${v3dt.urn}" />
<arg line="-p${CTSMAPI.package}=${CTSMAPI.urn}" />
<arg line="-p${CTSVAPI.package}=${CTSVAPI.urn}" />
<arg line="-y WRAPPED" />
<arg line="${wsdlClass}" />
(I also feed in an implementation with the -i flag so that it can pick
up the variable names)
And Axis2:
<arg line="-o ${wsdl.target.dir}" />
<arg line="-of ${wsdlTarget}.wsdl" />
<arg line="-tn ${wsdlUrn}" />
<arg line="-stn ${wsdlUrn}" />
<arg line="-sn ${wsdlTarget}Service"/>
<arg line="-cn ${wsdlClass}" />
The code that I feed into Axis2 is also annotated like this:
package org.hl7.CTSVAPI;
import javax.jws.WebParam;
import javax.jws.WebService;
@WebService
(
targetNamespace="urn://hl7.org/CTSVAPI"
)
public interface RuntimeOperations extends
org.hl7.CTSVAPI.IdentificationOperations
{
org.hl7.CTSVAPI.CodeSystemIdAndVersions[] getSupportedCodeSystems
(@WebParam(name="timeout") int timeout, @WebParam(name="sizeLimit")
int sizeLimit) throws org.hl7.CTSVAPI.TimeoutError,
org.hl7.CTSVAPI.UnexpectedError;
.....
Which does work wonderfully, I must say. The annotation method of
keeping the parameter names is much slicker than the Axis1 method of
having to pass in an implementation class. I even managed to hack
together a script to automate annotating all of the method names.
Thanks,
Dan
Re: AXIS2 - Sad State of code generation tools?
Posted by Amila Suriarachchi <am...@gmail.com>.
Can you send the wsdl files generated by both Axis1 and Axis2?
thanks,
Amila.
On Tue, Apr 15, 2008 at 9:07 AM, Amila Suriarachchi <
amilasuriarachchi@gmail.com> wrote:
>
>
> On Mon, Apr 14, 2008 at 2:31 AM, Dan Armbrust <
> daniel.armbrust.list@gmail.com> wrote:
>
> > I have come into Axis2, trying to bring some older code up to date
> > that was first done with Axis 1.
> >
> > My master API is written as IDL. In Axis1, the path that was taken
> > was IDL -> Java -> WSDL -> Java -> Implement these stubs.
> >
> > While not straightforward, this did work, without any major issues.
> >
> > Now, I get a 1.3 version of Axis 2, to try to "upgrade" my code - and
> > I'm left with the distinct feeling that the code generation tools in
> > Axis2 aren't yet worthy of a 1.0 release number.
> >
> > (I'm not looking to step on any toes... please don't take it the wrong
> > way - it's entirely possible I'm misusing the tools - so if there
> > things I can do to address the following issues, please correct me -
> > but it just seems like things aren't close to ready for primetime yet)
> >
> > 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.
>
>
> >
> > UnexpectedError.java
> > UnexpectedError5.java
> > UnexpectedError5Exception.java
> >
> > 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.
>
> >
> >
> > 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, it seems that I'm stuck. These interfaces are too large to be
> > handcrafting this code. I could probably write scripts that could
> > automatically fix the issues with the generated WSDL, but then
> > signatures for the server side stubs that I generate from the WSDL are
> > way off from what was specified in the IDL, mostly due to the
> > Exception unwrapping issues.
>
>
> 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.
>
>
> >
> >
> > Even if I were to dive in, and try to fix all of these issues in the
> > code generators, I sure haven't gotten much confidence that Axis2 will
> > work properly at runtime, given all of the issues I've had so far.
>
>
> 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).
>
> >
> >
> > And now I see that you are pushing toward a 1.4 release, while there
> > are still 31 "critical" bugs open when I search on wsdl. Many of
> > which probably cover and/or overlap the issues I have described here.
> >
> > Are these issues just not on anyone's radar, or priority list?
> >
> > Is the rest of Axis2 in better shape than this - does it work for
> > folks with real world apps? Or should I just go back to Axis1?
> >
> > 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.
--
Amila Suriarachchi,
WSO2 Inc.
Best practices for certificates
Posted by SG...@intellicare.com.
Opinions or pointers to references addressing these question appreciated:
Do you self-sign the certificates you use for signing and encrypting web
service traffic? Does this establish sufficient trust?
Do you use a well-known certificate authority to sign/create your
certificates? Are there any out there that even provide certificates for
web service encryption/signing??
Are the SSL certificates that most vendors sell suitable for web service
signing and encryption?
I hope this is a suitable topic for this group. I haven't found much
information other than what vendors have to say and they are 1. not
objective (see this interesting article:
http://www.schneier.com/paper-pki.html) and 2. not oriented to securing web
services (seem to know mostly about SSL certificates for web servers).
Thanks!
______________________________________________
Steve Gruverman, Programmer
IntelliCare, Inc. | A Medco Health Solutions Company
500 Southborough Drive | South Portland ME 04106
p: (207) 253-2152 | f: (207) 773-1857
w: www.intellicare.com | e: sgruverman@intellicare.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: AXIS2 - Sad State of code generation tools?
Posted by Amila Suriarachchi <am...@gmail.com>.
On Mon, Apr 14, 2008 at 2:31 AM, Dan Armbrust <
daniel.armbrust.list@gmail.com> wrote:
> I have come into Axis2, trying to bring some older code up to date
> that was first done with Axis 1.
>
> My master API is written as IDL. In Axis1, the path that was taken
> was IDL -> Java -> WSDL -> Java -> Implement these stubs.
>
> While not straightforward, this did work, without any major issues.
>
> Now, I get a 1.3 version of Axis 2, to try to "upgrade" my code - and
> I'm left with the distinct feeling that the code generation tools in
> Axis2 aren't yet worthy of a 1.0 release number.
>
> (I'm not looking to step on any toes... please don't take it the wrong
> way - it's entirely possible I'm misusing the tools - so if there
> things I can do to address the following issues, please correct me -
> but it just seems like things aren't close to ready for primetime yet)
>
> 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.
>
> UnexpectedError.java
> UnexpectedError5.java
> UnexpectedError5Exception.java
>
> 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.
>
>
> 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, it seems that I'm stuck. These interfaces are too large to be
> handcrafting this code. I could probably write scripts that could
> automatically fix the issues with the generated WSDL, but then
> signatures for the server side stubs that I generate from the WSDL are
> way off from what was specified in the IDL, mostly due to the
> Exception unwrapping issues.
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.
>
>
> Even if I were to dive in, and try to fix all of these issues in the
> code generators, I sure haven't gotten much confidence that Axis2 will
> work properly at runtime, given all of the issues I've had so far.
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).
>
>
> And now I see that you are pushing toward a 1.4 release, while there
> are still 31 "critical" bugs open when I search on wsdl. Many of
> which probably cover and/or overlap the issues I have described here.
>
> Are these issues just not on anyone's radar, or priority list?
>
> Is the rest of Axis2 in better shape than this - does it work for
> folks with real world apps? Or should I just go back to Axis1?
>
> 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.
Re: AXIS2 - Sad State of code generation tools?
Posted by Martin Gainty <mg...@hotmail.com>.
Wow
A quick browse of the site and I did'nt see
Transaction Code listing A01/A03/A08
http://www.xmlconverters.com/standards/hl7/
Segment listing PID, IN1, DG1 etc..
http://www.ringholm.de/docs/00710_en.htm
?
Thanks.
Martin-
----- Original Message -----
From: "Dan Armbrust" <da...@gmail.com>
To: "Martin Gainty" <mg...@hotmail.com>; <ax...@ws.apache.org>
Sent: Sunday, April 13, 2008 6:07 PM
Subject: Re: AXIS2 - Sad State of code generation tools?
> The spec I am working from is CTS:
>
> http://informatics.mayo.edu/LexGrid/index.php?page=ctsspec
>
> So that is where all of these data types that I reference originates from.
>
> I'm not actually getting any errors at the moment - the main problem I
> have is that the generated interfaces are just way off from the IDL
> spec - and I didn't have this issue with Axis1.
>
> In Wsdl - I see 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>
>
> ..
> <wsdl:message name="UnexpectedError">
> <wsdl:part name="parameters" element="ns0:UnexpectedError"/>
> </wsdl:message
>
> ...
>
> <wsdl:operation name="getSupportedMatchAlgorithms">
> <wsdl:input
> message="ns0:getSupportedMatchAlgorithmsRequest"
> wsaw:Action="urn:getSupportedMatchAlgorithms"/>
> <wsdl:output
> message="ns0:getSupportedMatchAlgorithmsResponse"
> wsaw:Action="urn:getSupportedMatchAlgorithmsResponse"/>
> <wsdl:fault message="ns0:UnexpectedError"
> name="UnexpectedError"
> wsaw:Action="urn:getSupportedMatchAlgorithmsUnexpectedError"/>
> </wsdl:operation>
> ...
>
>
> But then in the generated java, (wsdl -> java) I get something more like
this:
>
> public boolean isConceptIdValid(org.hl7.CTSVAPI.ConceptId concept_id4,
> boolean activeConceptsOnly)
> throws UnknownCodeSystemException3, UnexpectedErrorException4;
> UnexpectedErrorException4;
>
> (also note the weird number on the variable which should be named
"concept_id"
>
> And I have classes like this:
>
> public class UnexpectedErrorException4 extends java.lang.Exception {
> private org.hl7.CTSVAPI.UnexpectedError7 faultMessage;
>
> ....
>
> public class UnexpectedError7 implements
org.apache.axis2.databinding.ADBBean {
> public static final javax.xml.namespace.QName MY_QNAME = new
> javax.xml.namespace.QName("urn://hl7.org/CTSVAPI",
> "UnexpectedError", "ns1");
>
> ....
>
> public class UnexpectedError extends org.hl7.CTSVAPI.Exception
> implements org.apache.axis2.databinding.ADBBean {
>
>
> The CTS code is all open, from that website, so I can give you info on
> how to get the Java code (that comes out of the IDL conversion) if you
> want to test things yourself.
>
> Thanks,
>
> Dan
>
>
>
> On Sun, Apr 13, 2008 at 4:43 PM, Martin Gainty <mg...@hotmail.com>
wrote:
> > I have'nt heard of UnexpectedError5 in fact the closest datatype
definitions
> > I have is from enterprise.wsdl e.g.
> > <!-- assume this namespace -->
> > <definitions xmlns:fns="urn:fault.enterprise.soap.sforce.com">
> >
> > <!-- I see this definition of UnexpectedError -->
> > <complexType name="UnexpectedErrorFault">
> > <complexContent>
> > <extension base="fns:ApiFault"/>
> > </complexContent>
> > </complexType>
> >
> > Can you display any information on where you see this UnexpectedError5
> > (logs/StackTrace with the UnexpectedError5) ?
> >
> > Martin
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: AXIS2 - Sad State of code generation tools?
Posted by Dan Armbrust <da...@gmail.com>.
The spec I am working from is CTS:
http://informatics.mayo.edu/LexGrid/index.php?page=ctsspec
So that is where all of these data types that I reference originates from.
I'm not actually getting any errors at the moment - the main problem I
have is that the generated interfaces are just way off from the IDL
spec - and I didn't have this issue with Axis1.
In Wsdl - I see 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>
..
<wsdl:message name="UnexpectedError">
<wsdl:part name="parameters" element="ns0:UnexpectedError"/>
</wsdl:message
...
<wsdl:operation name="getSupportedMatchAlgorithms">
<wsdl:input
message="ns0:getSupportedMatchAlgorithmsRequest"
wsaw:Action="urn:getSupportedMatchAlgorithms"/>
<wsdl:output
message="ns0:getSupportedMatchAlgorithmsResponse"
wsaw:Action="urn:getSupportedMatchAlgorithmsResponse"/>
<wsdl:fault message="ns0:UnexpectedError"
name="UnexpectedError"
wsaw:Action="urn:getSupportedMatchAlgorithmsUnexpectedError"/>
</wsdl:operation>
...
But then in the generated java, (wsdl -> java) I get something more like this:
public boolean isConceptIdValid(org.hl7.CTSVAPI.ConceptId concept_id4,
boolean activeConceptsOnly)
throws UnknownCodeSystemException3, UnexpectedErrorException4;
UnexpectedErrorException4;
(also note the weird number on the variable which should be named "concept_id"
And I have classes like this:
public class UnexpectedErrorException4 extends java.lang.Exception {
private org.hl7.CTSVAPI.UnexpectedError7 faultMessage;
....
public class UnexpectedError7 implements org.apache.axis2.databinding.ADBBean {
public static final javax.xml.namespace.QName MY_QNAME = new
javax.xml.namespace.QName("urn://hl7.org/CTSVAPI",
"UnexpectedError", "ns1");
....
public class UnexpectedError extends org.hl7.CTSVAPI.Exception
implements org.apache.axis2.databinding.ADBBean {
The CTS code is all open, from that website, so I can give you info on
how to get the Java code (that comes out of the IDL conversion) if you
want to test things yourself.
Thanks,
Dan
On Sun, Apr 13, 2008 at 4:43 PM, Martin Gainty <mg...@hotmail.com> wrote:
> I have'nt heard of UnexpectedError5 in fact the closest datatype definitions
> I have is from enterprise.wsdl e.g.
> <!-- assume this namespace -->
> <definitions xmlns:fns="urn:fault.enterprise.soap.sforce.com">
>
> <!-- I see this definition of UnexpectedError -->
> <complexType name="UnexpectedErrorFault">
> <complexContent>
> <extension base="fns:ApiFault"/>
> </complexContent>
> </complexType>
>
> Can you display any information on where you see this UnexpectedError5
> (logs/StackTrace with the UnexpectedError5) ?
>
> Martin
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org