CXF java2ws: how to include external xsd files? - java

I generate WSDL files for several web services (from the server service definitions) where I have already XML schemas (*.XSD) for the beans used as parameters. How do I tell java2ws to reference these (include the external XSD) and not generate its own into the WSDL?
I have tried the -createxsdimports, but that does generate its own XSD files.
Is there a Java Annotation that I can use to let CXF know where the XSD for each file/package is?

Try the #XmlSchema annotation. It includes a location parameter that is used to tell JAXB that a real schema exists:
#XmlSchema(location="http://www.example.com/xsds/foo.xsd")
package com.example.foo;

I have a CXF Webservice that imports external schema files. When I built it; I spent quite a bit of time trying to sort out the exact scenario you're trying to achieve. Unfortunately, it appears that CXF does not respect the #XmlSchema(location="") annotation when generating WSDL from java. Daniel Kulp, the main CXF dev told me at the time this was a known issue but not enough people are complaining about it so it's not high on their list of priorities to fix.
So I ended up writing the WSDL by hand and then generating the SEI from the WSDL file. Of course, if you hand-write the WSDL you can do whatever you want.
Do bear in mind that one side-effect of this is that the external schema file needs to be accessible by an HTTP GET - both while generating the SEI AND when the webservice app starts up - CXF will retrieve the schema file on startup. Same goes for when you generate the client, of course. This does create a bit of a messy architectural dependency; but there appears to be no way to tell CXF "myschema.xsd" is available at http://myurl.com/myschema.xsd but ALSO in /src/main/schema/myschema.xsd.

Related

Java.xml.validation.Schema from wsdl

So I have a web service in NetBeans 8.1, for which I've written the wsdl with embedded XSD (and an external ref also).
Now I need to be able call the SOAP service on other instances of the application:
i.e. have instance X call a method on instance Y, as a secondary goal of the application.
I don't like to use NetBeans automatic SOAP client wizards, as I would be pointing to the very service which I'm building - it would potentially be a chicken and the egg type of thing during building. Secondly, I already have all the required JAXB types used by the web service, so it should be easy to construct a client right?
Well my trouble starts when I want to use JAXB to marshal my request object into a javax.xml.soap.SOAPBodyElement (my current strategy is to use SAAJ for the client part), but how to add a Schema to the marshaller? the schema is embedded in the wsdl, and I can't figure out how to reference it.
I figured that I could split out the schema part into a separate XSD file, but I'm missing an annotation option for #WebService, where I can provide an XSD file, just like I can provide a wsdl file (currently the 'wsdlLocation' points to both wsdl & xsd as it is embedded).
I guess I may have to live with not doing XSD validation on the client side(it is enabled server-side), as it seems tricky to get a Schema object from the wsdl - is that possible somehow?
You can read the .wsdl as an InputStream and transform it to a DOMResult. You can then get the "schema" node from the DOMResult and turn it into a DOMSource. With that, you can make a Schema object using the Source[] constructor.
I haven't got it to work myself, I had too many imports and it became hell to manage the namespaces. The only code I found on this was in "SOA Using Java Web Services" by Mark Hansen, chapter 7.5.1: Validation. I don't think I can put that code here, but all the code you should need for this use case is in there.

Web service SOAP integration

Im a bit confused. I have a WS which has different "message format" than another WS I have seen in the past.
The vendor provided me a set of messages which they can accecpt (I have tested in SoapUI and it really works - well)
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"xmlns:urn="urn:SAMPLE">
<soapenv:Header/>
<soapenv:Body>
<urn:CustomEnvelope>
The problem is, that in place where CustomEnvelope is used I would expect any method name (something like urn:calculateSum).
When I have tried to generate java client using Axis2, than in case od ADB databinding method I got uncompileable code. When I have used another one, I had on my Stub object only method named (for example) calculateSum and generated message doesn't correspond to the expected schema (instead od CustomEnvelope) there was used calculateSum.
My question is. Do you know what this strange format means? And have you any suggestion how to integrate such strange WS? I think about creating the whole XML using JAXB (vendor has provided a XSD files) and sending to the WS or creating SOAPMessages using standard Java API. But I am not sure what is there the best sollution.
Thanks, Ondrej
I had this issue during the Axis 2 client side stub generation, which gives you uncompileable code. Error is at the ADBDataSource class.
If this is your problem then here is the solution. What I did in my project, we are using WebSphere as the web application server and it contains a jar file (Something)ThinClient.jar in the class path of your project.
Now this jar also contains same class called ADBDataSource but its an abstract class. Which conflicts with our stubs because it creates object of ADBDataSource.
I suggest try to find out that do you have a such jar or not.
Solution
Remove (Something)ThinClient.jar or one which has same class from your class path.
If removing (Something)ThinClient.jar creates problem, then change the approach and use Jax-Ws insteadof Axis 2, which is part of Java it self. (This is what I did.)

How can I generate a WSDL file from a WSDL URL?

My problem is that I created a web service client with wsimport and when creating its service object, it fails because of the HTTPS, like that:
MyService_Service service = new MyService_Service(
new URL("https://www.aaa.com/myws/MyService?WSDL"));
So, I am trying to initialize a service object from a WSDL file, but how can I create a WSDL file from that URL "https://www.aaa.com/myws/MyService?WSDL"?
Thanks a lot.
Navigate to the URL in a browser and save the file it generates. You'll need to make sure you also save any schemas imported by the wsdl.
JAX-WS needs WSDL document every time one initializes service instance. Since issues like one you described might occur, its possible to package WSDL and associated XSD schemas, so that they would be accessible no matter what.
I'd prefer using XML catalogs, since there would be no need to change WSLD document or XSD schema.
Another option would be to specify #WebService wsdlLocation property and set path to WSDL file. Though if path to XSD schemas is absolute you'll have to modify WSLD document.
If you're working with wsimport utility version that supports clientjar option, that might save you some time.
Creates the jar file of the generated artifacts along with the WSDL
metadata required for invoking the web service.

Auto Generate REST Client from WADL

Are there any tools to auto generate a Command Line REST Client from WADL, something close to xmlBeans which can generate Bean classes from WSDL?
I have tried cxf-wadl2java and wadl2java.
cxf-wadl2java : This is throwing a lot of errors in the generated code and is actually generating the Producer classes rather than the consumer classes.
wadl2java : Even after fixing the repositories, I was unable to make this thing work. Get a lot of errors and no documentation at all except for what ever is on that specific page.

Using HP SOA Systinet Java API to upload a WSDL file

Does anybody have any idea of how this can be accomplished?
I can create wsdlArtifacts, businessServiceArtifacts, webServiceArtifacts, etc, but I can't upload a WSDL file, I would like to have the same behaviour of the Systinet interface, that is, the file is parsed and operations, endpoints, WSDL artifacts are automatically created. I don't want to have to parse the WSDL file to create those.
Thanks!
Disable the parsing policies associated to the WSDL artifact on systinet.

Categories