I am getting the below exception when generating pojos from WSDL.
External DTD: Failed to read external DTD 'XMLSchema.dtd', because
'http' access is not allowed due to restriction set by the
accessExternalDTD property.
I found solution in [WebService Client Generation Error with JDK8
[1]: WebService Client Generation Error with JDK8 where someone has mentioned to add below jvm argument.
-Djavax.xml.accessExternalSchema=all
How do I add this argument in jvm 1.8(fyi I am using macos) or run wsimport with above jvm argument?
I struggled with the same issue as you.
There are two ways to do that (at least those I have found).
The simply one is to invoke the WsImport as a java class via the java command with this concrete attribute:
java -Djavax.xml.accessExternalSchema=all \
-Djavax.xml.accessExternalDTD=all \
-cp /path/to/jdk/lib/tools.jar com.sun.tools.internal.ws.WsImport \
-d destination -s source wsdl_file_location
Explanation:
I invoke the concrete class (com.sun.tools.internal.ws.WsImport) that is also called from the wsimport command. I have chosen this way, as the problem is that wsimport does not provide any option to specify additional jvm arguments, this workaround was fastest for me.
Second option is to modify the JVM parameters. For that you can refer to:
jvm configuration
Related
WS Import issue in netbeans when try to create webservice client in maven project using wsdl.
--- jaxws-maven-plugin:2.3:wsimport (wsimport-generate-v34.0) # masterdata-workday ---
Processing: file:/C:/Users/ei10441/OneDrive%20-%20DEVRY/Documents/NetBeansProjects/masterdata-workday/src/wsdl/wdd9-impl-services15.workday.com/xxx/service/chuto1/Human_Resources/v34.0.wsdl
jaxws:wsimport args: [-keep, -s, C:\Users\ei10441\OneDrive - DEVRY\Documents\NetBeansProjects\masterdata-workday\target\generated-sources\jaxws-wsimport, -d, C:\Users\ei10441\OneDrive - DEVRY\Documents\NetBeansProjects\masterdata-workday\target\classes, -verbose, -encoding, UTF-8, -extension, -Xnocompile, -p, com.devry.masterdata.workday, -catalog, C:\Users\ei10441\OneDrive - DEVRY\Documents\NetBeansProjects\masterdata-workday\src\jax-ws-catalog.xml, -wsdllocation, https://wdd9-impl-services15.workday.com/xxx/service/chuto1/Human_Resources/v34.0?wsdl, "file:/C:/Users/ei10441/OneDrive%20-%20DEVRY/Documents/NetBeansProjects/masterdata-workday/src/wsdl/wdd9-impl-services15.workday.com/xxx/service/chuto1/Human_Resources/v34.0.wsdl"]
unrecognized parameter -
Usage: wsimport [options] <WSDL_URI>
where [options] include:
-b <path> specify jaxws/jaxb binding files or additional schemas
(Each <path> must have its own -b)
-B<jaxbOption> Pass this option to JAXB schema compiler
-catalog <file> specify catalog file to resolve external entity references
supports TR9401, XCatalog, and OASIS XML Catalog format.
-d <directory> specify where to place generated output files
-encoding <encoding> specify character encoding used by source files
-extension allow vendor extensions - functionality not specified
by the specification. Use of extensions may
result in applications that are not portable or
may not interoperate with other implementations
-help display help
-httpproxy:<proxy> set a HTTP proxy. Format is [user[:password]#]proxyHost:proxyPort
(port defaults to 8080)
-keep keep generated files
-p <pkg> specifies the target package
-quiet suppress wsimport output
-s <directory> specify where to place generated source files
-target <version> generate code as per the given JAXWS spec version
Defaults to 2.2, Accepted values are 2.0, 2.1 and 2.2
e.g. 2.0 will generate compliant code for JAXWS 2.0 spec
-verbose output messages about what the compiler is doing
-version print version information
-fullversion print full version information
-wsdllocation <location> #WebServiceClient.wsdlLocation value
-clientjar <jarfile> Creates the jar file of the generated artifacts along with the
WSDL metadata required for invoking the web service.
-generateJWS generate stubbed JWS implementation file
-implDestDir <directory> specify where to generate JWS implementation file
-implServiceName <name> local portion of service name for generated JWS implementation
-implPortName <name> local portion of port name for generated JWS implementation
Extensions:
-XadditionalHeaders map headers not bound to request or response message to
Java method parameters
-Xauthfile file to carry authorization information in the format
http://username:password#example.org/stock?wsdl
-Xdebug print debug information
-Xno-addressing-databinding enable binding of W3C EndpointReferenceType to Java
-Xnocompile do not compile generated Java files
-XdisableAuthenticator disable Authenticator used by JAX-WS RI,
-Xauthfile option will be ignored if set
-XdisableSSLHostnameVerification disable the SSL Hostname verification while fetching
wsdls
Examples:
wsimport stock.wsdl -b stock.xml -b stock.xjb
wsimport -d generated http://example.org/stock?wsdl
------------------------------------------------------------------------
BUILD FAILURE
------------------------------------------------------------------------
Total time: 27.405 s
Finished at: 2020-04-22T14:44:08+05:30
Final Memory: 14M/309M
Failed to execute goal org.jvnet.jax-ws-commons:jaxws-maven-plugin:2.3:wsimport (wsimport-generate-v34.0) on project masterdata-workday: Mojo failed - check output -> [Help 1]
To see the full stack trace of the errors, re-run Maven with the -e switch.
Re-run Maven using the -X switch to enable full debug logging.
For more information about the errors and possible solutions, please read the following articles:
[Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
Any idea what is issue and how to fix it in netbeans?
Changed the folder structure to one without hyphen and space and this got fixed for me.
It appears may be "OneDrive - DEVRY" is getting stucked
I am getting error while trying to build a java project in TeamCity. The same project builds and excecutes well on my local. I recently pushed changes to this project on GitLab. This is my first time working with GitLab and TeamCity together. Other projects have no issues during build. I am unable to understand what is causing this error:
[15:58:54][Step 1/1] compile.earCommons (4s)
[15:58:54][compile.earCommons] echo
[15:58:54][compile.earCommons] echo
[15:58:54][compile.earCommons] wlcompile (4s)
[15:58:59][wlcompile]
com.bea.util.jam.internal.javadoc.JavadocClassloadingException: An error
has occurred while invoking javadoc to inspect your source
files. This may be due to the fact that $JAVA_HOME/lib/tools.jar does
not seem to be in your system classloader. One common case in which
this happens is when using the 'ant' tool, which uses a special
context classloader to load classes from tools.jar.
This situation elicits what is believed to a javadoc bug in the initial
release of JDK 1.6. Javadoc attempts to use its own context classloader
tools.jar but ignores one that may have already been set, which leads
to some classes being loaded into two different classloaders. The
telltale sign of this problem is a javadoc error message saying that
'languageVersion() must return LanguageVersion - you might see this
message in your process' output.
This will hopefully be fixed in a later release of JDK 1.6; if a new
version of 1.6 has become available, you might be able to solve this
by simply upgrading to the latest JDK.
Alternatively, you can work around it by simply including
$JAVA_HOME/lib/tools.jar in the java -classpath
parameter. If you are running ant, you will need to modify the standard
ant script to include tools.jar in the -classpath.
[15:58:59][Step 1/1] Process exited with code 1
[15:58:59][Step 1/1] Ant output
[15:59:10][Step 1/1] Process exited with code 1 (Step: Ant)
[15:58:59][Step 1/1] Step Ant failed
****Update****
Build Step: Ant
Step 1:
Runner type: Ant (Runner for Ant build.xml files)
Execute: If all previous steps finished successfully
build.xml file: \ant\build.xml
Working directory: same as checkout directory
Targets: none specified
Ant home path: C:\apache-ant-1.7.0
Additional Ant command line parameters: -lib c:\WebLogic\12.1.2\wlserver\server\lib\javaee.jar;c:\WebLogic\12.1.2\wlserver\server\lib\weblogic.jar;c:\WebLogic\12.1.2\wlserver\server\lib\webservices.jar
JDK home path: c:\Program Files\Java\jdk1.7.0_80
JVM command line parameters: not specified
Reduce test failure feedback time: OFF
Java code coverage: disabled
Docker Settings
Docker Image: unset
I'll appreciate any help in this regard.
I found there was character encoding issue with one of the files that prevented compiler from loading the java classes. Once that was fixed, the build worked fine.
We are upgrading our gsoap version from 2.7.8 to the latest version 2.8.33
When our make file runs soapcpp2.exe and wsdl2h.exe with the exact same flags, I don't get the exact same classes and API, so I figured I'll have to tweak them a little bit.
We used to run soapcpp2.exe with these flags: -C -L -x -I
The first noticeable change was classes inheriting from structs soap rather than pointing to them. I was able to solve this compatibility issue by adding -j.
Now, I am encountering another incompatibility where a function
SOAP_FMAC5 int SOAP_FMAC6 soap_serve_request(struct soap *soap)
is absent.
I searched the gsoap code and found it, so I guess there's some way to make gsoap to generate it. Is there really a way to make gsoap generate this function, or will I have to adjust my code/ write the function myself
The gsoap tools have options to support backward compatibility. Run soapcpp2 -h to see your options:
Usage: soapcpp2 [-0|-1|-2] [-C|-S] [-T] [-Ecdt] [-L] [-a] [-A] [-b] [-c|-c++|-c++11] [-d path] [-e] [-f N] [-h] [-i] [-I path:path:...] [-l] [-m] [-n] [-p name] [-Q name] [-q name] [-r] [-s] [-t] [-u] [-v] [-w] [-x] [-y] [-z#] [infile]
...
...
-z1 compatibility: generate old-style C++ service proxies and objects
-z2 compatibility with 2.7.x: omit XML output for NULL pointers
-z3 compatibility with 2.8.30 and earlier: _param_N is indexed globally
Try -z1.
PS. The old proxy and service classes with option -z1 are more simplistic, the new classes generated with option -j are an improvement. But when you're generating service classes with -j the C-like API with global functions are gone (a good thing IMO).
I am trying to hit the following web service with axis2: http://www.webservicex.net/geoipservice.asmx?WSDL
I have Axis2 locally, and I generated my classes by downloading the wsdl to my local drive and running:
./wsdl2java.sh -uri geoipservice.wsdl -p geoip -d xmlbeans -s -o geoip
This produced a build directory with a build.xml file in it, which i then ran "ant" in, and it produced a client jar in the libs folder.
I dropped this jar onto my classpath, and then I tried to hit the service using the following code:
GeoIPServiceStub stub = new GeoIPServiceStub("http://www.webservicex.net/geoipservice.asmx?WSDL");
GetGeoIPDocument req = GetGeoIPDocument.Factory.newInstance();
GetGeoIP gic = req.addNewGetGeoIP();
gic.setIPAddress("74.125.91.105"); // google.com
GetGeoIPResponseDocument resp = stub.getGeoIP(req);
System.out.println(resp.getGetGeoIPResponse().toString());
Things seem to run at first, and I see the results coming back in the syslog, but before it finishes it throws this exception:
java.lang.NoSuchMethodError: org.apache.axiom.om.impl.OMStAXWrapper.<init>(Lorg/apache/axiom/om/OMXMLParserWrapper;Lorg/apache/axiom/om/OMElement;Z)V
at org.apache.axiom.om.impl.llom.OMStAXWrapper.<init>(OMStAXWrapper.java:52)
at org.apache.axiom.om.impl.llom.OMElementImpl.getXMLStreamReader(OMElementImpl.java:795)
at org.apache.axiom.om.impl.llom.OMElementImpl.getXMLStreamReaderWithoutCaching(OMElementImpl.java:765)
at geoip.GeoIPServiceStub.fromOM(GeoIPServiceStub.java:767)
at geoip.GeoIPServiceStub.getGeoIP(GeoIPServiceStub.java:325)
I've googled all over and haven't been able to find what is causing this. Can anyone help me find what I'm doing wrong? Thank you.
You get NoSuchMethodErrors if your compiler used a different class definition (during compilation) to create your .class file then the jvm has at runtime.
In your case, it misses the constructor for org.apache.axiom.om.impl.OMStAXWrapper(org.apache.axiom.om.OMXMLParserWrapper, org.apache.axiom.om.OMElement)
It probably means you have the wrong org.apache.axiom library somewhere on your classpath.
I'm trying to consume a webservice in java, using a client generated from the wsdl file with wsdl2java.
I'm using Eclipse version Helios and jdk 1.6.0_20, and I've generated the .class files using wsld2java with the options:
"-d c:\WebServices\Generated -client -verbose -compile -autoNameResolution -p org.dwservice -sn DWService -wsdlLocation /WEB-INF/wsdl/DWService.wsdl c:\WebServices\DWService.wsdl"
I packed the resultant files into a .jar and added it to my project that compiles ok.
But when I try to use the webservice, I got the exception:
javax.xml.ws.WebServiceException: Port {http://tempuri.org/}WSHttpBinding_IDWService not found.
at org.apache.cxf.jaxws.ServiceImpl.getPort(ServiceImpl.java:311)
at org.apache.cxf.jaxws.ServiceImpl.getPort(ServiceImpl.java:302)
at javax.xml.ws.Service.getPort(Service.java:92)
at org.dwservice.DWService.getWSHttpBindingIDWService(DWService.java:63)
And this is my code:
import org.dwservice.*;
...
private DWService dwService = new DWService();
private IDWService iDWService = ***dwService.getWSHttpBindingIDWService()***;
Any idea would be very much appreciated.
I know this post is over a year old, but it's a highly ranked search result for this error. I'm adding this answer for posterity.
Your wsdl2java command suggests your WSDL is local and you're packaging it into a web app. I suspect the app isn't finding the packaged WSDL at runtime. One option is to load it as a Java resource and pass its location into your service's constructor:
QName qname = new QName("my.name.space", "myName");
URL wsdlLocation = MyServiceClient.class.getResource("/WEB-INF/wsdl/DWService.wsdl");
dwService = new DWService(wsdlLocation, qname);
If you use this approach, triple-check the path to your WSDL. It's easy for getResource() to silently fail, which will produce the same error.