I have started on using Swagger. At this point, I have received a swagger file for swagger version 1.2. However, if I want to generate something with this file, it just gives me a bunch of errors that look more like it just ignores the fact that my swagger file is in version 1.2 spec and just goes ahead and validates it against version 2.0 of the spec.
Some of the errors I got:
Missing required property: paths
Additional properties not allowed:
models,apis,resourcePath,swaggerVersion,apiVersion
...
The last error tells me that apiVersion is unknown, although the gitHub page claims that the latest stable is supposed to be compatible with version 1.0, 1.1, 1.2 and 2.0. Is there a way that I can "force" the generator to think 1.2 spec instead of 2.0 spec?
I've verified with an official 1.2 spec yaml file too:
https://raw.githubusercontent.com/swagger-api/swagger-codegen/v2.0.18/samples/yaml/pet.yml
But it gives the same errors when you load it in the Swagger editor:
http://editor.swagger.io/#/
The swagger-codegen project relies on the swagger-parser, which has a module called swagger-compat-spec-parser which will actually convert your 1.2 specification into 2.0 format before passing on to the code generator.
The errors you're seeing are because that conversion has failed. You can save you swagger 1.2 files locally, tweak them, and re-run the processing.
The challenge with the 1.2 to 2.0 conversion is that swagger 1.2 did not initially have a schema to validate against. Thus there are a lot of invalid swaggers out there, and it's technically impossible to convert all the different issues in 1.2 specs into 2.0.
That said, we are always trying to make the tooling better so if you find a "repeatable" bug in the 1.2 converter, file an issue in the swagger-spec project and we'll see about fixing it (most are easy).
Related
While building the code getting package sun.security.action is not visible
Package sun.security.action is declared on module java.base, which does not export it to the unnamed module.
What should I do.
Kindly advice, Thanks in advance
Java 8 had no module system - everything is visible or just needs to get imported by archives in jdk (f.e. tools.jar).
Java 9 brought JMS and encapsulated some jdk classes.
In your case, see <JAVA_HOME>/lib/src.zip!/java.base/module-info.class:
exports sun.security.action to
java.desktop,
java.security.jgss,
jdk.crypto.ec,
jdk.incubator.foreign;
Your package isn't public but restricted to some other internal packages/modules.
There was a workaround by adding compiler option --add-exports=java.base/sun.security.action=ALL-UNNAMED at compile time to fix this limitation until version 16.
With version 17 and JEP 403 forget all hope:
It is not a goal to define new standard APIs to replace internal elements for which standard replacements do not yet exist, though such APIs could be suggested in response to this JEP.
Backwards compatibility and important frameworks have lower priority than jdk security - JCP makes strange decisions and works against the community sometimes -.-
I am using Struts 2.1 in my project.
In struts.xml maxsize element in my project is as follows :
<constant name="struts.multipart.maxSize" value="2147483648" />
For the file upload process,
is it possible to supersede the normal 2 Gb file limit of Struts2 ?
You should migrate to the latest version of Struts2.
From 2.3.20 and above, a new MulitpartRequest implementation can be used to upload large files:
Alternate Libraries
The struts.multipart.parser used by the fileUpload interceptor to
handle HTTP POST requests, encoded using the MIME-type
multipart/form-data, can be changed out. Currently there are two
choices, jakarta and pell. The jakarta parser is a standard part of
the Struts 2 framework needing only its required libraries added to a
project. The pell parser uses Jason Pell's multipart parser instead of
the Commons-FileUpload library. The pell parser is a Struts 2 plugin,
for more details see:
http://cwiki.apache.org/S2PLUGINS/pell-multipart-plugin.html. There
was a third alternative, cos, but it was removed due to licensing
incompatibilities.
As from Struts version 2.3.18 a new implementation of MultiPartRequest
was added - JakartaStreamMultiPartRequest. It can be used to handle
large files, see WW-3025 for more details, but you can simple set
<constant name="struts.multipart.parser" value="jakarta-stream" />
> in struts.xml to start using it.
Trying to achieve this proposal to make a div size based on its background image I'm using Less 2.5.1 compiled by Web Essentials 2013 for Update 4 version 2.5.4 and some functions do not resolve:
My Less File:
.myClass{
height:image-height("myUrl.png"); //<-- Do not resolve
width:percentage(1/2); //<--Resolves
}
Resolved Css File:
.myClass{
height:image-height("myUrl.png"); //Not good
width:50%; //Good
}
I'm having this problem with image-height, image-width and image-size. Not with the rest of Misc Functions
There's no problem resolving the image by the compiler, because it's working fine when I used it like:
background-image:url("myUrl.png");
In the documentation there's a note for these methods saying:
Note: this function needs to be implemented by each environment. It is
currently only available in the node environment.
In the WebEssentials documentation it says:
Web Essentials uses the node-less compiler and it always uses the
latest version
And
NodeJS compilation - Web Essentials uses NodeJS to run the compiler.
It's the fastest and most accurate compiler for LESS available.
I'm missing something that I don't know. What does that note mean? What
should I do?
I've create a jsfiddle to share with you my goal.
Validation framework which has been rolled up as part of the JEE6 spec (WL12). Both the WL10 and WL12 versions of our application were deployed with the following open source libraries:
JSR-303 / validation-api.jar (version 1.0)
Hibernate Validator (version 4.2.0)
However, the libraries are also bundled with WL 12 (modules directory). Note that the Hibernate Validator version is slightly different.
modules.javax.validation_1.0.0.jar
hibernate.validator_4.1.0.jar
With our WL12 run we are getting below exception:
javax.validation.ValidationException: Unable to get available provider
Attempted Solutions
Our next attempt was to use the WebLogic FilteringClassLoader to prefer the libraries from our application (APP-INF/lib directory) by specifying them in the weblogic-application.xml file (i.e. choose our versions over WebLogic’s). We were already doing this for several other open source libraries in WL10:
<prefer-application-packages>
<package-name>com.google.common.*</package-name>
<package-name>org.apache.commons.lang.*</package-name>
<package-name>org.apache.commons.logging.*</package-name>
<package-name>org.apache.commons.beanutils.*</package-name>
<package-name>org.apache.commons.collections.*</package-name>
<package-name>antlr.*</package-name>
<package-name>javax.validation.*</package-name>
<package-name>org.hibernate.validator.*</package-name>
</prefer-application-packages>
After making that change, our application experienced the following run-time error trying to process any request that makes use of the validation framework:
javax.validation.ValidationException: Unable to get available provider resolvers.
at javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:259)
at web20.hibernate.validation.ValidatorFactoryConfigurator.getValidatorFactory(ValidatorFactoryConfigurator.java:39)
at web20.hibernate.validation.ValidationHandlerImpl.handleHibernateValidations(ValidationHandlerImpl.java:180)
at web20.hibernate.validation.ValidationHandlerImpl.performValidation(ValidationHandlerImpl.java:255)
at web20.hibernate.validation.ValidationHandlerImpl.validateAndFormatMessages(ValidationHandlerImpl.java:302)
at web20.hibernate.validation.ValidationHandlerImpl.validateUsingHibernateGroups(ValidationHandlerImpl.java:113)
at service.serviceapp.performValidations(serviceapp.java:392)
at service.serviceapp.performValidations(serviceapp.java:379)
at service.TransactionalServiceImpl.search(TransactionalServiceImpl.java:300)
Given that Bean Validation is part of the EE standard, I assume there is some code Bean Validation integration code which causes the problem. I see two potential solutions:
Patch the WL instance and upgrade to the Validator version you want to use
Try writing your own ValidationProvider. Internally it could just delegate to the Hibernate Validator classes. If you then add a validation.xml to your application, specifying your custom provider, WL should bootstrap this one. TBH, I don't know whether this will work. There are many unknowns and I don't know enough about the integration of WL and Bean Validation.
Personally, I think I would just try to upgrade the Validator version used in WL.
I'm on TCL 8.5 (can't upgrade) and running version 2.7.7 of the HTTP package. I'm calling a library which appears to be using the following http::geturl command to download an image which has been gzipped:
http::geturl $url -headers {Accept-Encoding gzip}
and I'm getting this error:
invalid command name "zlib"
Searching on the web, I could only find this reference to the bug which basically recommends stopping sending Accept-Encoding gzip, which I can't do (nor can I upgrade to 8.6) http://sourceforge.net/p/tcl/bugs/4784/
My question is: is there any 8.5 workaround for this issue? Is there a way to stop this library from sending the "Accept-Encoding gzip" header?
The issue is that the code believes you've got the zlib package (which supplies the zlib command) available, and so turns on support for gzip-compressed streams. The simplest fix in your code is to do:
package require zlib
So long as this happens before you call into the code that does the http::geturl, this should be enough.
If you don't have the package (in which case you'll get a clear failure from the package require) then you've hit a bug either where the soft dependency code in the http package is getting it wrong when building the request headers, or in the server which is sending gzipped data despite not being asked for it. The code pointed to from TIP #234 (i.e., the SVN repository at http://svn.scheffers.net/zlib) contains the source for a version of the zlib package, in particular it's the version that formed the starting point for the built-in support in Tcl 8.6, but I think it only uses Tcl 8.5 APIs.
Unhelpfully, there are several versions of the zlib package around; this is one of the messiest Tcl packages to acquire, alas.