We want to split our swagger specifications into two files. One containing the endpoints and one containing the type definitions because the type definitions are used in multiple projects and we want to avoid fixing something in multiple source locations.
We are using the maven codegen plugin to generate the model and the api and it works fine with the splitting.
However the request validation does not because it is not able to follow the external references to the type definitions it seems.
We are using swagger-request-validator-springmvc for the request validation. Unfortunately only one resource is allowed and it does not expand/merge the multiple specifications into one as swagger-codegen does.
When running the swagger-codegen in verbose mode a "merged" swagger specification is shown in the log. Is there a way to get codegen to export this merged specification?
Or is there another way to get the request validation going with multiple specification files?
When running the swagger-codegen in verbose mode a "merged" swagger specification is shown in the log. Is there a way to get codegen to export this merged specification?
If I am understanding this correctly, you want the whole swagger specification when using the maven plugin. This is usually generated in the output folder specified in the plugin configuration.
<plugin>
<groupId>io.swagger</groupId>
<artifactId>swagger-codegen-maven-plugin</artifactId>
<version>${swagger.codegen.maven.plugin.version}</version>
<executions>
<execution>
<phase>generate-sources</phase>
<goals>
<goal>generate</goal>
</goals>
<configuration>
...
<output>${project.build.directory}/generated-sources/swagger</output>
...
</configuration>
</execution>
</executions>
</plugin>
I cannot understand your second question however - can you please elaborate?
Or is there another way to get the request validation going with multiple specification files?
Related
I have a working vaadin-8 application. I want to migrate this application to vaadin-23.I have added dependencies related to vaadin-23
<dependency>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-bom</artifactId>
<version>${vaadin23.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
i am able to create views based on vaadin-23. But the problem is my vaadin-23 views with #Route annotation are not being used. I am not able to hit those urls from the browser. Do I need to create some servlet for vaadin-23 as I did for vaadin-8?
If the application is not using Spring check this example project for step by step migration from Vaadin 8 to Vaadin 14 running both apps at the same time in the same workspace. Scenario with Vaadin 23 should not be different regarding project setup. github.com/TatuLund/migrate-v8-to-v14/tree/master
But if you use Spring Boot, that is most likely the case. Both Vaadin versions require different version of the Spring add-ons, and those in turn define new scopes and there will be a clash.
In such case one can always deploy two different wars either on different context paths or different ports. Naturally you should keep the projects separated and use different IDE instance for each one. But if your requirement is to keep two apps running on the same server, so that it is easy to switch between them, it will work for that purpose.
We use Apache Ant for our project build and were thinking of extending the same for getting swagger 2.0 specs .json generated for our REST API docs. I found an ant task : https://github.com/cstroe/swagger-ant-task
which would invoke the same swagger core maven plugin, but some dependency jars have been changed in the github package due to which I am getting 'No Such Method' Exception for getApiInfo() method in ApiSourceInfo.java.
We cannot use maven just for generating API docs. I needed some help in finding a way by which I can use swagger core tool of generating docs using swagger annotations in the API definition file. Using ant wrapper for the maven plugin was one way but I am not not able to leverage it. Is there any other workaround?
Or to frame it otherwise, whats the right swagger tool/plugin to generate Swagger 2.0 jsons out of JaxRS annoations which works with ANT.
Any suggestion would be much appreciated.
Thanks
I am trying to follow this tutorial to create DropWizard views. However, when I try to addBundle(new ViewBundle()), it fails to find (or import) ViewBundle. What am I missing here?
The dependency dropwizard-views was missing in my maven pom file. Adding the dependency solved the issue.
<dependency>
<groupId>io.dropwizard</groupId>
<artifactId>dropwizard-views</artifactId>
<version>${dropwizard.version}</version>
</dependency>
You will need to choose one of the view template. As of writing, Dropwizard supports FreeMarker and Mustache. Instead of including dropwizard-view dependency, you should choose either dropwizard-views-mustache or dropwizard-views-freemarker, and dropwizard-view will be included as dependency.
I have the same JSF war deployed in two environments, both environments are apparently identical (Weblogic 10.3.3). There is no entry in the web.xml for javax.faces.VALIDATE_EMPTY_FIELDS.
In one of the environments, the validators are getting invoked on empty fields and in the other they are not.
The JSF war and the application code is EXACTLY the same.
The JSF Specification version is 2.0 and Implementation Version is 1.0.0.0_2-0-2. I know I can add the parameter javax.faces.VALIDATE_EMPTY_FIELDS in web.xml to ensure identical behavior in all environments, but I want to know why they have a different default behavior? Is it possible that it could be something related to presence of JSR 303 validation in one environment and not in another? How do I check this?
JSR 303 validation is auto enabled if the implementation jar is on the classpath.
Is there any tool for generating Java code from WSDL using XML Catalogs? The problem is that I have wsdl files that import XML schemas which also import other schemas and the schemas are not available at schemaLocation url. That is why code generation fails. If a tool was able to use XML Catalog this problem would be solved without modifying each schemaLocation in each WSDLs and schemas.
I have tried Eclipse and Netbeans plugins but both failed. In Eclipse and Netbeans I have configured alternative schema locations by using XML Catalog and so they can validate WSDL files without error. However, when they generate code from wsdl they fail.
Just found that JBoss's wsconsume tool is able to consume XML Catalogs for entity resolution and it works fine.
http://community.jboss.org/wiki/JBossWS-wsconsume
Just for the record: i've set up a small exemple project on Github that uses an XML schema. it may be of any help: https://github.com/fmarot/xml-mapping-tutorial
Be sure to check its wiki too in order to have an overview: https://github.com/fmarot/xml-mapping-tutorial/wiki
The WSDL has to be valid without the use of XML catalogs, or clients consuming that WSDL will not be able to consume it.
Of course, if you will never use any clients not running on the JBoss platform, then you'll be fine.
Meanwhile, I found an other solution that fits the best to my needs. There is a maven plugin called jaxws-maven-plugin that is also able to handle XMLCatalogs when generating sources from wsdl.
https://jax-ws-commons.dev.java.net/jaxws-maven-plugin/
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxws-maven-plugin</artifactId>
<version>1.10</version>
<executions>
<execution>
<id>id1</id>
<phase>generate-sources</phase>
<goals>
<goal>wsimport</goal>
</goals>
<configuration>
<verbose>true</verbose>
<keep>true</keep>
<catalog>${basedir}/src/main/resources/catalog.xml</catalog>
<packageName>org.example</packageName>
<wsdlDirectory>
${basedir}/src/main/resources/contracts/wsdl/ExampleService/1
</wsdlDirectory>
<wsdlFiles>
<wsdlFile>ExampleService_1_0.wsdl</wsdlFile>
</wsdlFiles>
<xadditionalHeaders>false</xadditionalHeaders>
</configuration>
</execution>
</executions>
<configuration>
</configuration>
<dependencies>
<dependency>
<groupId>com.sun.xml.ws</groupId>
<artifactId>jaxws-tools</artifactId>
<version>2.1.7</version>
</dependency>
</dependencies>