Coder Social home page Coder Social logo

Comments (13)

JFCote avatar JFCote commented on June 9, 2024 1

@acabarbaye I created a PR last friday. It just needs to be reviewed and the feature should work.

from openapi-style-validator.

JFCote avatar JFCote commented on June 9, 2024

Hi @acabarbaye ,

There will be a new parameter for this, it has been added last week with this issue: #135

We should release a new version with this improvement somewhere next week. In the meantime, you can compile the code of the project in the master.

Let me know if this new feature is ok for your use case.

from openapi-style-validator.

JFCote avatar JFCote commented on June 9, 2024

@acabarbaye It has been released in version 1.5. Please let us know if it's working for you and we will close this issue :)

from openapi-style-validator.

acabarbaye avatar acabarbaye commented on June 9, 2024

@JFCote : has version 1.5 made it to maven central or Jcenter?

   > Could not find org.openapitools.openapistylevalidator:openapi-style-validator-cli:1.5.
     Searched in the following locations:
       - https://jcenter.bintray.com/org/openapitools/openapistylevalidator/openapi-style-validator-cli/1.5/openapi-style-validator-cli-1.5.pom
       - https://jcenter.bintray.com/org/openapitools/openapistylevalidator/openapi-style-validator-cli/1.5/openapi-style-validator-cli-1.5-all.jar
       - https://repo.maven.apache.org/maven2/org/openapitools/openapistylevalidator/openapi-style-validator-cli/1.5/openapi-style-validator-cli-1.5.pom
       - https://repo.maven.apache.org/maven2/org/openapitools/openapistylevalidator/openapi-style-validator-cli/1.5/openapi-style-validator-cli-1.5-all.jar

Just to be sure I understand the new feature, for my case, I should define the following options?

{... 
  "validateNaming": true,
  "ignoreHeaderXNaming": true,
  "headerNamingStrategyConvention": HyphenCase,
}

from openapi-style-validator.

JFCote avatar JFCote commented on June 9, 2024

@acabarbaye Oh! It seems the release didn't make its way to Maven. I will check with @jmini who did the release. Will update here when it's ready.

As for your problem, I now see that it will not fix your issue because the naming of your header is not the same. At first glance, I thought that it was the same thing as #135

What you need would be an option to completely ignore the naming of headers. I will think about it. Maybe a new "naming strategy convention" that will be Anything?

from openapi-style-validator.

JFCote avatar JFCote commented on June 9, 2024

@acabarbaye There was a problem during the release, the 1.5 was lost. It has been generated again and it's there! https://repo1.maven.org/maven2/org/openapitools/openapistylevalidator/openapi-style-validator-lib/1.5/

from openapi-style-validator.

acabarbaye avatar acabarbaye commented on June 9, 2024

@acabarbaye There was a problem during the release, the 1.5 was lost. It has been generated again and it's there! https://repo1.maven.org/maven2/org/openapitools/openapistylevalidator/openapi-style-validator-lib/1.5/

Perfect.
I will give it another try but I think your suggestion of having a Anything option would make a lot of sense

from openapi-style-validator.

gervaisb avatar gervaisb commented on June 9, 2024

I have documented some official headers like Accept-Encoding and If-None-Match. However they did not pass any naming convention. I tried AnyCase but received a NullPointerException.

Anyway, Can't we exclude official headers from the naming convention validation or include a naming convention that match the official "Hyphen-Upper-Case" ? And/or maybe ensure that official headers match the official naming convention ?

Edit; The NullPointerException is gone with v1.6.

from openapi-style-validator.

JFCote avatar JFCote commented on June 9, 2024

@gervaisb Just to be sure, is it ok now or do you still have problems with the AnyCase naming convention?

from openapi-style-validator.

gervaisb avatar gervaisb commented on June 9, 2024

Well the issue with AnyCase is that it accept anything. I still feel that there is a missing HyphenUpperCase style to validate headers like Accept-Encoding.

from openapi-style-validator.

gervaisb avatar gervaisb commented on June 9, 2024

Hello. Can we reopen that issue ?

I have tried the version 1.7 but the "Hyphen-Upper-Case" cause a NPE.

Exception in thread "main" java.lang.NullPointerException
at org.openapitools.openapistylevalidator.NamingValidator.isNamingValid(NamingValidator.java:82)
at org.openapitools.openapistylevalidator.OpenApiSpecStyleValidator.validateNaming(OpenApiSpecStyleValidator.java:207)
at org.openapitools.openapistylevalidator.OpenApiSpecStyleValidator.validate(OpenApiSpecStyleValidator.java:35)
at org.openapitools.openapistylevalidator.cli.Main.validate(Main.java:62)
at org.openapitools.openapistylevalidator.cli.Main.validateAndPrint(Main.java:47)
at org.openapitools.openapistylevalidator.cli.Main.main(Main.java:36)

I would like to:

  • Patch OpenApiSpecStyleValidator.validateNaming(..) so that it accepts the "Hyphen-Upper-Case" naming convention.
  • Update README.md to document that naming convention.
  • Manage this NullPointerException to provide a detailed error message with all supported naming convention.

from openapi-style-validator.

JFCote avatar JFCote commented on June 9, 2024

@gervaisb Issue reopened!

from openapi-style-validator.

gervaisb avatar gervaisb commented on June 9, 2024

I have tried the version 1.7 but the "Hyphen-Upper-Case" cause a NPE.

I do not know what happened with 1.7, but I have made another attempt right now (Oct. 5 2021) and it seems that HyphenUpperCase is a supported naming convention in version 1.7. 🎉

Anyway, I still have to update the README and manage the NullPointer. However, the NullPointerException occurs because Gson ignores unknown values for enums. So we have to either validate that there are no null naming conventions in ValidatorParameters (once parsed), but then we do not have the original values to provide a complete error message. Another solution would be to validate them against the enum values before the parsing (this is my favourite solution).

Whatever the choice, the Main class does not have a validation mechanism for the parameters. A quick solution would be to validate into the Main class, right after optionManager.getOptionalValidatorParametersOrDefault (L62) and throws IllegalArgumentException that will be caught aside of the ParseException (L42). But this is not ideal and there should be a more complete solution to validate the parameters/options.

Do you have any advice on where and how that validation should be implemented?

from openapi-style-validator.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.