I am trying to generate java classes that describe the web service offered here which belongs to this page. Please mind that I am not convinced that the XML is the one needed to run the following steps!
I save the XML of the API to a file: getcapabilities.xml
I run the following trang command to generate an XSD: java -jar trang.jar getcapabilities.xml getcapabilities.xsd
I get the following files: getcapabilities.xsd, ogc.xsd, wfs.xsd, xlink.xsd, xsi.xsd
I run the following command to generate java classes: xjc getcapabilities.xsd
The following error message is prompted
parsing a schema... [ERROR] no-xsi: The {target namespace} of an attribute declaration must not match 'http://www.w3.org/2001/XMLSchema-instance'.
line 7 of file:xsi.xsd
Failed to parse a schema.
Questions:
Do you get the same error message?
What can I do about it?
Is my approach meant to be successful at all?
You're dealing with an OGC Web Feature Service. There's a couple of peculiarities with that.
Don't generate you schemas with trang, you can get them from OGC: http://schemas.opengis.net/wfs/1.1.0/
You don't really have to compile these schemas on your own, you can get them precompiled from the OGC Schemas and Tools project (JARs are here).
WFS schemas only describe WFS operations - they are kind of container schemas. You'll also have an application profile which describes your features. You can obtain it via the DescribeFeatureType operation: http://data.wien.gv.at/daten/wfs?service=WFS&request=DescribeFeatureType&version=1.1.0
Consider using someting like GeoTools.
Related
I want to get all destinations on subaccount and instance level. In SAP API business Hub, I found the API information and "SAP Cloud SDK" tab to generate code by OpenAPI generator.
https://api.sap.com/api/SAP_CP_CF_Connectivity_Destination/overview
I downloaded the API specification and added dependencies into Cloud SDK for Java project. The code is generated successfully with some errors (unknown models）in generated api classes.
For example in DestinationsOnSubaccountLevelApi.class, model OneOfDestinationNameOnly is imported and used in method but it is not generated in model package.
I looked into API specification and found that there were two types of response entity. That is the reason why the code could not be generated properly. I can modify the API specification to make it work but it should not be the long term solution. Is there any other way to fix this issue?
Unfortunately the SAP Cloud SDK Generator for Open API services is not yet able to understand oneOf relationship that is modeled in the specification.
As an alternative, would you consider using the DestinationAccessor API for resolving single destinations?
You can also directly instantiate an ScpCfDestinationLoader, which allows for querying all destinations:
ScpCfDestinationLoader loader = new ScpCfDestinationLoader();
DestinationOptions options = DestinationOptions
.builder()
.augmentBuilder(ScpCfDestinationOptionsAugmenter.augmenter().retrievalStrategy(ScpCfDestinationRetrievalStrategy.ALWAYS_SUBSCRIBER))
.build();
Try<Iterable<ScpCfDestination>> destinations = loader.tryGetAllDestinations(options);
Similar to the default behavior of DestinationAccessor API, in the code above only the subscriber account will be considered. Other options are:
ScpCfDestinationRetrievalStrategy.ALWAYS_SUBSCRIBER
ScpCfDestinationRetrievalStrategy.ALWAYS_PROVIDER
ScpCfDestinationRetrievalStrategy.SUBSCRIBER_THEN_PROVIDER
I have a micronaut API like this:
#Get("/")
List<Club> listClubs()
#Get("/{id}")
Club show(Long id)
In my unit test, when I invoke the show method, the listClubs() method is actually getting invoked, instead.
Why is this happening?
Details:
Thinking that my URL mappings must be wrong, I started debugging into Netty to try to understand how the framework constructs URLs.
In HttpClientIntroductionAdvice, the context shows the API method like this:
Club show(Long param0)
The interceptor is setting param0 in the parameter map, which doesn't match the actual parameter name of my method. When the URI template is expanded, this causes the ID to get dropped (thus the URI becomes / instead of /1).
I am trying to follow this example:
https://github.com/alvarosanchez/micronaut-workshop/tree/master/ex02/solution/clubs
There is one important different in my project, which is that the endpoint is set at "/club" instead of at "/":
#Controller("/club")
#Client("/club")
I am using a diff tool to compare my project to the sample, but I am struggling to find any other difference (besides package name changes).
Why is this happening? What should I be looking for?
Thanks
Update:
Tested the target endpoint with the browser - looks fine.
Gradle clean does not resolve the issue.
I switched from debugging the Application class with IntelliJ to using "gradlew run" and in the process, I made a change to build.gradle (adding JVM properties pass-through from the gradle CLI). I also played with enabling/disabling the annotation processor in the IDE.
(note: In the previous project, I enabled annotation processing as soon as I imported into the IDE. On this project, I didn't enable it until I started having issues.)
I think the build.gradle alteration caused the problem to go away. Since the issue shows up unreliably, it's hard to tell for certain if this is the change that caused it to be fixed.
I am part of a project written in TypeScipt and I am trying to add TypeScript Web Server which will be compatible with Swagger.
What is the most basic strategy to implement it, considering easy maintainability.
For Typescript I have notice that exists 'Typson' library for generating a JSON Model from TypeScript Interface.
For Swagger, I have tried using 'swagger-node-restify' library, since it supports adding JSON models to swagger.
However, I encounter some problems:
Typson doesn't support typeScript syntax of Import -
(import {Server} from "restify")
I tried to implement the 'swagger-node-restify' example (Pet Example), however the RESPONSE of the localhost:8080/api-docs.json GET Request is missing all the SPEC data of the API.
{"apiVersion":"0.1","swaggerVersion":"1.1","basePath":"http://localhost:8080","apis":[{"path":"/api-docs.{format}/pet","description":"none"}]}
I suggest to describe a Swagger compliant API using yaml or json and to generate the server from that.
swagger-server can build APIs on top of express in real time (no source code generation).
There are JavaScript code generators :
Call the swagger-codegen client with -l nodejs-server
swagger-node is a great alternative but seems hard to integrate with TypeScript
Yes, you can easily generate Swagger and OpenAPI documents from your TypeScript types by using tsoa. The readme contains all of the setup information that you would need to start using it. It's compatible with express, hapi, koa, and more (via the ability to add your own template for your preferred server type):
https://github.com/lukeautry/tsoa
The advantages that tsoa has over other libraries is:
it both generates the swagger/OpenAPI document and it also validates the types at runtime
(Full Transparency: I am one of the maintainers of tsoa. But I was first a consumer of tsoa and I find it to be a great product... that's why I asked to help maintain it! :) )
In Mule ESB I want to validate incoming SOAP/XML, using a standard Mule "schema-validation filter".
Something like:
<mulexml:schema-validation-filter schemaLocations="xxx.xsd" name="xxxValidationFilter"/>
However this kind of definition seem to assume that the schema is located in a separate xsd-file, whereas in a lot of cases the schema definition is embedded in the "wsdl:types" element of a wsdl-file.
Is there any way to use the Mule schema-validation-filter to validate against schema's which are embedded in the wsdl (except for copying the schema element definitions out of the
wsdl and into a separate xsd-file).
Mule service element tags which expose the service haave an attribute that can enable validation on the incoming request.
validationEnabled="true"
<cxf:simple-service validationEnabled="true"/>
<cxf:jaxws-service validationEnabled="true"/>
<cxf:proxy-service validationEnabled="true"/>
For more information refer to the following Mule documentation link.
http://www.mulesoft.org/documentation/display/current/Building+Web+Services+with+CXF
Hope this helps.
I'm having some problems trying to consume a web service from a groovy script. I'm using WSClient lib.
If I execute the example posted at groovy's website:
#Grab(group='org.codehaus.groovy.modules', module='groovyws', version='0.5.2')
import groovyx.net.ws.WSClient
proxy = new WSClient("http://www.w3schools.com/webservices/tempconvert.asmx?WSDL", this.class.classLoader)
proxy.initialize()
result = proxy.CelsiusToFahrenheit(0)
println "You are probably freezing at ${result} degrees Farhenheit"
Works fine, but once I try to consume another service it crashes with this error:
INFO: Created classes: javac: no
source files Usage: javac
use -help for a list
of possible options 07-jul-2010
9:55:57
org.apache.cxf.endpoint.dynamic.DynamicClientFactory
createC lient GRAVE: Could not compile
java files for http://xxx:8080/x/services/xxx?wsdl.
Caught:
groovyx.net.ws.exceptions.InvokeException:
java.lang.NullPointerExceptio n
at groovy-ws.run(groovy-ws.groovy:13)
The code it's exactly the same (apart from wsdl url which correponds to one internal server). The main difference I found between them is that the second wsdl is RPC style while the first one isn't. I've read that there's some problems to consume RPC like webservices from groovy with WSClient lib. ¿Does anyone know how to consume RPC like webservices with WSClient? ¿Could anyone enlighten me please?
Thank you very much
There seems to be a bug in GroovyWS, documented here on their JIRA.
It's currently Unresolved and was added in 2010.
I'm personally getting the same error with anything other than the trivial example service, with Groovy 1.8.0, GroovyWS 0.5.2
Hopefully somebody can find the issue and fix it - WSClient could definitely be a great alternative to traditional CXF/JAXB
Don't use WSClient is the best answer I can give you. For anything but simple services I've found WSClient does not work well. Instead use what ever java based web service client your most comfortable with and call it from Groovy.