i'm trying to use swagger-codegen-maven-plugin to generate my interface .
after compiling with the plugin - it generates all the files correctly but for some reason
the interface name is DefaultApi.
i looked for some configuration that i can change the name of the interface that been generated but didnt find the solution for that.
any idea on that??
"DefaultApi" is used when there's no tags specified for the endpoint.
For example, this endpoint will be put in a class named "UserApi" since the tags is set to User.
You will need to update the spec to include proper tags for endpoints to avoid using "DefaultApi"
UPDATE: On May 2018, about 50 top contributors and template creators of Swagger Codegen decided to fork Swagger Codegen to maintain a community-driven version called OpenAPI Generator. Please refer to the Q&A for more information.
Related
(Sample) Problem:
When a yaml source contains conflicting definitions, e.g. myClass and MyClass both generating into a java class MyClass with one overwriting the other, no warning or error occurs.
Other similar cases can occur the same way (e.g. via implicitly generated classes from complex entries of type: array).
Framing
has to work without modifying the source file
there is exactly one source file, for whatever that's worth
has to work as a Maven plugin
tested with swagger-codegen-maven-plugin 2.4.0 and 2.4.22
am familiar with JAXB2 and both of its common Maven plugins:
jaxb2-maven-plugin
maven-jaxb2-plugin
am not familiar with swagger-codegen-maven-plugin
did not find solutions (or even corresponding problem reports) using Google searches
swagger codegen strict
swagger-codegen-maven-plugin strict
swagger codegen name collision
swagger-codegen-maven-plugin name collision
swagger codegen resolve name collision
swagger-codegen-maven-plugin resolve name collision
found this closed issue describing a similar issue (silently generates corrupt code), which appears to be mostly unrelated and is alledgedly long fixed
Question
What is the proper solution that produces
an eagerly failing generation process
amended via externally configured customBindings
without touching the yaml source file
?
Solution ideas:
Use JAXB2 instead
JAXB2
fails generation where a generated file already exists
allows a separate customBindings.xjs file to modify generation of
classes
can be adapted to work with YAML using
JacksonJaxbYAMLProvider
However it seems that the common Maven plugins jaxb2-maven-plugin and maven-jaxb2-plugin do not support YAMl definition files (out of the box?). [1]
Use Mustache files to resolve the name collision
The Mustache language seems to provide the necessary facilities to implement rules similar to JAXBs xjb.
However
binding a Mustache template to a class has to be done by name (<class name>.mustache), aka. name collision in particular cannot be resolved from an external file [2]
this does not help with the silence of errors in generated code - one cannot fix the error, while unaware of it
1 - Searches for this topic have yielded one result that it does not work out-of-the-box (duh) and no results whether it can be made to work using the extensions interface both plugins support.
2 - I could not find the relevant part directly within Swagger codegen documentation, but here is a relevant part of the implemented-by-Swagger OpenAPI generator documentation.
As the krakend.json is not of the type which swagger understands.Following error occurs:
Error: Document must be valid OpenAPI 3.0.0 definition
Is there any alternate way to generate documentation for krakenD
Generating both KrakenD configuration and OpenAPI documentation is possible, but...
You should precisely define your use case:
Do you want to generate krakend.json config from OpenAPI just as no-op proxy? (see an example script)
Are you willing to adopt another (custom) format? (see openapi2krakend)
Do you want to generate OpenAPI documentation from KrakenD config? If so, do you need just a list of endpoints or do you want also to have defined descriptions, examples and types (!) in one file?
You should (at least try to) write the script to generate the configuration by yourself to suit your needs.
Consider a usage of KrakenD Studio that has the OpenAPI generator plugin.
It can look like a good idea, but the devil is in the details and you should analyse your requirements because these two files have totally different purposes. I can only suggest you write such a transformation script (as I did) which should be like "5 minutes of work" and then go to the deep.
Edit: We have selected a subset of KrakendD features and implemented our own configuration generator (from OAS). We use tags with a custom route-to/ prefix for metadata, a definition could look like this:
/coupons/{id}:
get:
tags:
- Coupons
- route-to/path=/coupons/{id}/detail
- route-to/backend=GET|http://coupons.content
- route-to/flags=jwt_validation
the last two days I had the opportunity to play around with Micronaut.
It looks nice and I like the built in support for OpenAPI (Swagger). I managed to have the OpenAPI documentation in a local Swagger-UI and I was able to create some documentation which is shown in Swagger-UI as expected.
Then I moved to a little real world project which uses Lombok with fluent API which is configured in lombok.config
lombok.accessors.fluent=true
This setting causes Lombok not to create getter/setters, but something like
private String name;
public String name()...
public void name(String name)...
Unfortunately the OpenAPI documentation generation does not work properly in this setup - it is skipped. It seems the getter convention is required.
Is there any Micronaut-Swagger-Extension available which support the lombok fluent accessors?
If there is none, can you please give me any hint which piece of code scans the methods for annotations so I can extend it?
Thank you in advance!
UPDATE 1:
For better problem reproduction I enhanced the Micronaut Java Example: https://github.com/flexguse/micronaut-examples/tree/master/hello-world-java
The README.md contains detailed information, how to configure lombok to get the missing OpenAPI documentation.
No, Afaik there is no Micronaut Swagger extension for Lombok at the moment.
The OpenApiApplicationVisitor.java is responsible for generating OpenAPI documentation. And, if you are planning to work on micronaut-openapi for supporting the Lombok fluent accessors I would be happy to help.
We have an growing swagger API/openAPI and for documenting changes we like to document on a path or parameter (and perhaps definition) since which version of the API it is available.
The swagger specification knows the info.version field, but on paths or parameters I could not find something refering to this version.
Perhaps vendor extensions beginning with a x-... like x-since might be helpful. At least validation does not fail using them.
But is there perhaps any existing implementation for this use case?
I'm not aware of any existing attribute in OpenAPI/Swagger 2.0 spec to meet your need so you should go with vendor extensions (x-since, x-created-on, x-created-by, etc)
I'm having some trouble merging the localization satellite assemblies into the plugin DLL for CRM2011.
Either that, or I don't know how to use the merged resources afterwards.
I create a few plugins and create a basic resource file (default - English) and one for a specific culture (at the time of writing it's for Polish localizations, but later I'll need to add French as well).
I make sure not to sign the assembly itself, as ILMerge will sign the finished assembly itself.
This is the command I use to merge the extra satellite assembly:
ilmerge /targetplatform:v4,C:\Windows\Microsoft.NET\Framework\v4.0.30319 /log:log.txt /keyfile:KeyFile.snk /out:Plugins.dll DynamicsCRM2011.Plugins.dll pl-PL\DynamicsCRM2011.Plugins.resources.dll
As you can see, the plugins are in .NET 4.0 and I've got the required .config file for ILMerge to use the required assemblies for merging.
The generated file appears fine, I can register it with CRM plugin-registrator, add new steps and so forth.
However, it will always use the default language. I've tried changing the System.Threading.Thread.CurrentThread.UICulture, but this didn't help. When I created a ResourceManager class and used GetString("ErrorMessage", new System.Globalization.CultureInfo("pl-PL")), I got an Exception that the specified ResourceManager doesn't know what to do with the specified culture.
I know of this question here. However, the posted solution seems to be an old one. The generated resource .cs files do not use a ComponentResourceManager. Also, parts of the code posted there have been marked as deprecated.
I'm not really sure what I'm am to do now, or how to further debug this, as I have very little experience when it comes to working with assemblies themselves. Please, help me get those satellite assemblies under control.
Update:
I've been working with sandbox plugins for a while now, and thus I no longer have access to things such as CurrentCulture (or at least I cannot change such things). I've tried tackling this problem once more: I've created a simple plugin which is fired when a new Account is saved. Nothing fancy. Here's the actual plugin code:
ResourceManager rm = new ResourceManager(typeof(Properties.Resources));
var s = rm.GetString("ErrorAlreadyPosted", new System.Globalization.CultureInfo("pl-PL"));
throw new InvalidPluginExecutionException(s);
The code no longer throws an exception about not being able to find the specified culture... also the code obviously throws an exception at the end, but the important thing is WHAT the exception message is. I'd expect it to be in Polish.
Alas, it is not. The string returned by GetString is still in English.
The command I used for ILmerge is the same as before, but with the /lib parameter specified so that I don't have to copy all the CRM SDK dlls...
Apparently it is not possible to read resources from with the context of a Plugin.
Read up on MSDN: http://msdn.microsoft.com/en-us/library/hh670609.aspx#BKMK_UseXMLWebResourcesAsLanguageResources
Quote: When a plug-in requires localized text, you can use an XML web resource to store the localized strings so the plug-in can access them when needed. The structure of the XML is your option, but you may want to follow the structure used by ASP.NET Resource (.resx) files to create separate XML web resources for each language. For example, the following is an XML web resource named localizedString.en_US that follows the pattern used by .resx files.
This is all I know so far - have yet to build my own solution for localization of a crm plugin.
If you use a reflector tool to look at the generated assembly, do you see your resource(s) embedded correctly? You may be experiencing the bug as outlined in the link you posted.
Try setting Thread.CurrentThread.CurrentUICulture and\or Thread.CurrentThread.CurrentCulture.
Also try hooking into the AppDomain.CurrentDomain.AssemblyLoad and\or AppDomain.CurrentDomain.AssemblyResolve to debug which assemblies are being attempted to load and from where. You might need to customize their behavior so that instead of loading an external assembly to load an internal resource instead.
You can try embedding project references as resources instead of using ilmerge as well.
See this: http://bartlomiej.net/dotnet/embeded-assembies-into-an-executable/
The way we eventually handled this is by adding the localization XML files (generated by Visual Studio) as CRM resources, and created a bit of custom code which seeks the appropriate resource and then seeks the localization text inside.
It's, obviously, not as simple as just using the generated C# localization class, and requires some prep work. However, with that prep-work in place and with using nameof it's now almost as simple as the aforementioned resource classes.