I've generated stubs using following commands
Axis: java org.apache.axis.wsdl.WSDL2Java CrmDiscoveryServiceWsdl.xml : Generates all classes
Axis2 : wsdl2java.bat -u -uri CrmDiscoveryServiceWsdl.xml : Generates only a few classes.
Pattern I observed is, in the wsdl:types section, it has created classes for the <s:element> types but not <s:complexTypes>. I don't get why. I have to use those complexType elements to consume webservice.
I've also tried -pn, -ap options, thought they might work, but ports had nothing to with this. I understood after I did it.
Note: I could generate all with Axis2 when I use -ss -g options, which also generates server side. Obviously, it's a workaround and I don't need atleast some of them.
Please help.
Thanks.
I noticed this too with something a little different. Generating stubs with Axis2 1.6 against Great Plains 10, some types were missing. They were all xsd complex types which derived from other types in the schema definition. This only caused an error when parsing a response that included these missing types. The error was thrown from the ExtensionMapper.
After generating with the '-g' option, more types (including these missing derived types) are included in the ExtensionMapper and the problem is fixed.
I'm not sure what generating server side code has to do with properly parsing and generating the adb beans, but it works now.
There's also bug in the Apache Axis JIRA which mentions differing beans when using -g vs not using it:
http://issues.apache.org/jira/browse/AXIS2-3988
Related
A little configuration information to start:
Xcode 13
Qt 5.15.5
iOS 14.7.1 (18G82) (I'm running on a device, not a
simulator)
Host MacOS Big Sur 11.6
I'm debugging a large Qt app, all written in C++, except for the necessary few files to make it work in iOS (so it's really an Objective-C++ app with an enormous amount of native C++ linked to it, everything of Qt it needs). I have a break point within the LoadApplication method - Qt has been built from source for development (that is, in debug configuration with symbols). There are a number of native Qt QUrl objects whose values I'd like to inspect. I have successfully installed lldbbridge.py, but I think the problem may be unrelated to that, because I saw it when I was using other tricks to see the data without the bridge. There is a method called toString on the QUrl class that produces a text representation of the URL (and another called toDisplayString that may be more human readable). These methods produce (of course) QString objects. So here are the failure modes:
First the bridge should be helping me to inspect the QUrl and all I see are the raw object descriptions that hide all the private interfaces. It isn't.
before I installed the lldbbridge.py script, I was able to view some of these objects (local variables, but not parameters), using code like expr url.toString().toStdString().c_str(). It still might work on local variables, but I would really like to be able to inspect parameters as well.
the error feedback I get is
error: <lldb wrapper prefix>:21198:9: module 'std' not found
#import std;
~~~~~~~^~~
this is a pretty legit error, because I have scoured my system and the internet for evidence of this std.framework whose existence is implied, and cannot find it, though its name suggests that it would be an assist to Objective-C or Swift to deal with std::string and the like. Possibly it was a thing in Xcode 12 that has been dropped in Xcode 13, but if so, it has no footprint on the web that I can find. Still, presumably Qt 5.15.5's lldbbridge.py was compiled and run and against it at some point in the recent past.
this isn't the only trick that doesn't work when inspecting a QString, with or without the bridge. I also tried expr (const wchar_t*)url.toString().toUtf16() and expr (const char*)url.toString().toUtf8() and so forth. The same error feedback results, complaining about the mysterious "std" framework or module.
and don't get too hung up on QUrl objects, because I get the same result with other QStrings.
one more symptom: if I do an expr #import std; in the lldb command line, it appears to work. That is, it gives no error feedback and appears to complete. This just makes the world weirder, because if exists, it must be hiding somewhere inside Xcode's contents, but I've done file searches in there, and see no evidence of such a thing. And if it does exist, why is the lldb wrapper prefix giving me grief? Could the wrapper be underspecified in terms of framework search paths, but the lldb command line not?
So as if it's not too obvious, here are my questions (besides WTF???):
Am I the first to see this? I've seen some forum talk about string inspection no longer working for others in Xcode 13 lldb, but the specific failure mode is different. Anyone else see this?
Does anyone have any idea about this mysterious "std" framework or module? Could its functionality have been sucked up into some other module or framework for Xcode 13?
Any ideas about work-arounds that I haven't thought of? I'm not a complete lldb novice, but I'm not an expert either.
I'd like to turn up the log levels look at those for clues, but I've never used that feature before, and I don't really even know where to FIND the logs.
I notice that the feedback suggests that there are at least 21198 lines in this "wrapper" BEFORE we get to the failing import statement. Seems a little excessive to wrap a request to view the contents of a string. Perhaps the whole wrapper is corrupted in some way. Any thoughts on how to test that hypothesis? How about a way to inspect the contents of the wrapper prefix itself?
Could the #import std; be a red herring and just co-lateral damage in some other unrelated failure mode? It's tempting to imagine it's some kind of std library support thing, but I don't want to assume too much at this point.
one more things about "std", whatever it is - lldb is super dynamic. It's always compiling inline code on-the-fly to support its functionality. That's the whole llvm magic. Is it possible it exists only as some inline text within lldb's source? And again, if so, why is it only selectively available?
Well, that's my nightmare. Unless my setup is horribly corrupted in some way and it's my unique curse, I'm sure this problem will show up for others, so cogent answers will make you a hero. Any pointers are appreciated. Thanks.
I want to connect several webservices that share common object types. Using the internal tool from VS in the GUI: Add Service Reference… is not an option because it leads to several definitions of the same class types because of the different namespaces.
I tried the command line wsdl:
wsdl /sharetypes /language:CS /namespace:MyNameSpace /out:references.cs /protocol:SOAP http://AddressWS1?wsdl http://AddressWS2?wsdl http://AddressWS3?wsdl
this works, but I am a bit confused because I am used to work with the “app.config” file that does not exist here.
I also tried:
svcutil.exe /language:cs /out: references.cs /config:app.config http://AddressWS1?wsdl http://AddressWS2?wsdl http://AddressWS3?wsdl
it does not work as I get several errors of the type: “The global element xxx has already been declared.”
Is there a better solution?
Thanks for your help
Just because they appear to you (the developer) as the same shapes, the fact that they are in different namespaces, means that they ARE actually different and must be treated as such.
It's entirely possible that if you get your idea to work, one of the WebServices then decides to add another field to its response, but not the others, and then you have to split them again.
This issue describes the concept
https://github.com/dart-lang/source_gen/issues/272
To summarize:
I am using source_gen to generate some dart code.
I am using json_serializable on the generated dart code.
I wish to output all of the results to a source directory adjacent or below my target source.
The desired directory structure
src
feature_a
model.dart
gen
model.g.dart
model.g.g.dart
feature_b
...
I have considered building to cache however it seems json_serializable doesn't support this and even if it did I don't know if its even possible to run a builder on files in the cache.
I've also considered an aggregated builder that is mentioned here.
Generate one file for a list of parsed files using source_gen in dart
But json_serializable is still an issue and the source_gen version in that post is super old and doesn't describe the solution well.
This is not possible with build_runner. The issue to follow is https://github.com/dart-lang/build/issues/1689
Note that this doesn't help much with builders that you don't author, and wouldn't work with things like SharedPartBuilder.
as I am at my wits and I decided to post this also on StackOverflow.
I recently tried to create a basic Hello World web service (through the Function Builder), and turn it into a WSDL. Then using (Java) wsimport function turning it into java files.
The finction looks like this:
FUNCTION ZWEBSERVICE1.
write: / 'hello world'.
ENDFUNCTION.
The first problem I encountered is while executing wsimport. I got a error that states that wsdl:service is not in the file. After googling a while, I found no discussions/solutions to that problem. So I just wrote:
<wsdl:service name="ZWEBSERVICE1">
</wsdl:service>
into the file, and executed wsimport again, and got my java and class files.
The next problem I encountered is that the ZWEBSERVICE1.java class is somewhat empty... It looks like this:
...
public class ZWEBSERVICE1 {
}
... so now I am at my wits end, and hope that someone can give me some insight in what I did wrong.
I posted this as dicussion on SAP, so if there are any changes there I will update this topc.
http://scn.sap.com/thread/3800470
WRITE is used to produce ABAP lists for interactive display of offline usage within the ABAP system. It is not suitable for web services in any way. Since your function does not appear to have any parameters, it doesn't make much sense to turn it into a web service - I wouldn't expect anything but an empty WSDL file in this case...
I've created stubs using -d xmlbeans option. Here is the full command :
wsdl2java.bat -u -d xmlbeans -ns2p http://www.sugarcrm.com/sugarcrm=com.sugarcrm.data,http://schemas.xmlsoap.org/soap/encoding/=com.sugarcrm.schema.import1,http://schemas.xmlsoap.org/wsdl/=com.sugarcrm.schema.import2,http://www.w3.org/2004/06/xmlmime=com.sugarcrm.schema.import3 -p com.sugarcrm -uri Sugar\Sugar_V2_E.xml
Surprisingly, there are no getter methods in the 'returned' data types, which are supposed to be used to get information/results after communicating with the Server. Besides that, there are no setters to send the server some parameters to perform basic operations.
Here is the WSDL file
Ex: objects which have no getters (no methods at all) : EntryList, EntryListImpl; SelectFields, SelectFieldsImpl; etc.
Note: I had to use XMLBeans since Sugar WSDL defines rpc/encoded style.
Please help, I'm blocked.
Thanks.
Axis2 doesn't support RPC/Encoded. Using the XMLBeans binding will allow wsdl2java to complete, but it won't generate useful code as you've discovered.
Here is a somewhat out of date comparison of several of the major SOAP stacks, and you can see that RPC/Encoded isn't widely supported. Your best bet is probably to use Axis (not Axis2).