I'm more or less a beginner with web services but I've tried googling this with no results.
I have a web service written in Java using the Metro stack that runs fine when I run it on a local JBoss 5.1.0 instance but when I move it to our test server I start getting problems.
The service deploys correctly and I can view the WSDL as usual: https://myserver.myorg/path/service?wsdl
However, wsimport failed to generate client stubs from here and when I took a closer look at the WSDL I saw this:
<xsd:schema>
<xsd:import namespace="http://mynamespace/" schemaLocation="https://testserver.myorg:443/path/Service?null"/>
</xsd:schema>
Instead of what I would see when I ran it locally, which had the schemaLocation set to http://localhost:8080/path/Service?xsd=1
When I try putting in xsd=1 instead of null manually in a web browser, I get a 404 error.
Does anybody know what might cause this and how to fix it?
Thanks,
Raj.
I think the problem is that your XSD is behind an SSL connection, so your wsimport needs to know and trust the server SSL certificate.
For achieving this, you'll need to set up a new Java Keystore file (.jks file), or reuse an existing one if you already have it, add the server SSL certificate (for this, you can use the keytool provided with the JDK), and declare the Keystore a Trustore using the next JVM parameters on your wsimport invocation:
-Djavax.net.ssl.trustStore=${truststore.location} -Djavax.net.ssl.trustStorePassword=${ssl.password}
The test JBoss server is restarted weekly and following the restart, the XSD file is appearing properly. Sorry for the noise - I should learn to turn it off and on again before posting :).
Related
I need help on an error I get when trying to create a web service client in IBM RSA using the WTP wizard.
The error says :
IWAB0639E Error in generating Java files and deployment descriptors from WSDL file
WSWS3204E: Error: {http:// [...] .com/ChannelSvcs/BranchMgmt/Schema/V1}OrganizationUnitCodeType already exists.
Couldn't find any hint to a solution on the net, only this one :
http://www-01.ibm.com/support/docview.wss?uid=swg1PK40815
But this page also says :
This updated WSDL2Java will be included in Rational Application Developer v6.0.1.2.
But our environment is : IBM RSA Version: 7.5.5.5 iFix001
Build ID: RSA4WSO7555iFix-I20121203_0630
As a local fix this site suggests :
Modify the existing wsdl structure so as not to include the same xsd file more than one time.
But at this point I don't prefer a local fix, unless there's no permanent fix.
Ok, I talked to the guy who published the web service and he told me to use the wsdl file in the documentation, not the wsdl file on the server (via URL).
so I did that and it worked.
Looks like the server sends all .xsd files and the .wsdl file mixing it into one response file.
Still, IMHO wsdl2java should still be able to process such files.
I generate service code using the command
wsdl2java -uri AuthenticationService.wsdl [params]
then make changes to a few generated files and deploy my war file. But the issue is i have deployed this file to QA environment and it has a soap address (epr - end point reference) which is pointing to QA box.
<!-- Soap Service Endpoint -->
<service name="SforceAuthenticationService">
<documentation>Sforce Authentication Service</documentation>
<port binding="tns:AuthenticationBinding" name="AuthenticationService">
<soap:address location="https:[QA URL]/myapp/services/MyService"/>
</port>
</service>
To push to production it seems that in my wsdl file and i need to change the url and run the wsdl2java command again which will create new files, and then again i have to make changes in couple of java classes. Ideally i would like to push to production when QA signs off without having to build again! Is it possbile to do this by changing the soap address via admin console? I couldn't find anything on it.
I don't know whether its possible with wsdl2java. I couldn't quickly find anything to answer that. However it is possible to avoid this problem using other technologies. I'm not so familiar with using wsdls to generate as most of the time I have had to work from java. I have used spring-ws and jax-ws to generate ws from java. When going this way, the generated service run on a url at the server its deployed at, so there is no ever having to worry about the address. Maybe you should have a look at spring-ws and jax-ws, they probably hold the answer for you. Someone else maybe able to expand on what I've said.
I have a jar file which houses client code to connect to our infrastructure webservices that was initially created using axis' wsdl2java. I converted the guts of the connectivity this week to use the extract from wsimport. When running on my local Windows XP tomcat using java6_18 I have no issues and all runs perfectly. I have now moved my code to our development AIX instance and have lost total web service communication while receiving the following error:
XML reader error: javax.xml.stream.XMLStreamException:
The root element is required in a well-formed document
On AIX we are running java6_64.
I am assuming it is the AIX java libs not being compatible with the Sun provided java runtime libs however I am at a total loss at the moment as to how to resolve.
Can anybody shed some light on why I am receiving this exception?
This could be a code page issue as it complains that there is no root-element, and if the < character is misinterpreted as something else you have no root element.
Check the system properties to see what encoding the program runs under. You may have an assumption somewhere that the encoding is ISO-Latin-1 as under Windows.
I don't like answering my own question but thought recording the answer could be beneficial to others...
After digging a bit, the resolution was simply the format of the wsdl url. With axis, I specified the wsdl URL as the path to the webservice. For JAX-WS, it requires path to the service+"?wsdl" (the actual wsdl to load at runtime).
The above error was generated since the "axis" path did not result in the wsdl to pull but rather a blank resultset. Once I added the "?wsdl" all works fine.
I am working on creating a CAM (custom authentication module/provider) for Cognos 10.
Various encrypted information is passed into the provider from the query string. The Namespace's authentication process is then designed to talk to a web service in order to validate the encrypted information wasn't tampered with and to make sure the user's "session" in the authenticating application hasn't expired.
The authenticating application uses .NET and has the web service exposed for use with SOAP requests (1.1 and 1.2, I believe). I pointed wsimport at the wsdl and generated a set of classes that works when I build a standard Java console app and pass along debug values.
When I add this code into my Namespace class and attempt the request to the web service I am getting this error from Cognos:
com.sun.xml.internal.ws.spi.ProviderImpl (initialization failure)
I thought Cognos 10 was using JDK 1.6. I am developing my CAM code in 1.6 (64bit JDK). I should have 64bit Cognos running but I do not know if it is using a 32bit JDK. Could a possible disparity in 32bit vs. 64bit be causing the issue?
Any clue as to why the generated classes from wsimport (JAXWS) won't work in Cognos? Is there a way around this?
I'm going to mark this as answered but I'll put the caveat that I haven't tested this.
After dealing with trying to get 3rd party libraries to work with my CAP/CAM I figured that the reason JAXWS was not working correctly because Cognos didn't have that included in its Java distribution.
I got a similar error to the above when trying to use Microsoft's JDBC implementation to talk to a SQL server for namespace searches. This leads me to believe that the same situation exists with JAXWS.
I looked around for the jar file that should contain the classes that would need to be there. I didn't see any jar file that was named the same as what I have for 1.6. Unless it truly isn't supported in Cognos I think including the jar file for JAXWS in the WEB-INF/lib folder will allow webservice communications using JAXWS.
There is an SAP server that has some webservices I need to use, so I am trying to use wsimport to generate the client stubs.
I don't want to find all the wsdls and schemas that are referenced and modify them to do it locally, as that isn't sustainable, if they service should change.
So, how can I use wsimport to fetch a wsdl and generate the client stubs when the server is using Windows Integrated Authentication, where even the wsdl requires credentials.
The best solution I have found is to just copy the wsdl, and add in the changes to get it to work with wsimport, and save it on the jboss server, since it is unlikely someone will figure out the name of the directory, and only port 8009 is open to the world, even the jboss port is closed.
It isn't the best solution, but it works.