6fe9a52229
* Iniital docusaurus based site * Remove error about default local being used by String.format * Change pinned users to represent global presence rather than alphabetical order pinning * Include generator indexes in ensure-up-to-date (docusaurus site and /generators/README) * Add Font Awesome attribution footer * Remove feature callout until it is completed * Include NPM try it out section * Improve "Getting Started" type docs * Include new custom template documentation * Updating templating and customization docs * Add vendor extension docs * Cleanup templating page(s). * Move users to yaml file for easy edit. * travis configuration, and baseUrl mods to image URLs * [docs] Migrate FAQ, release summary from wiki FAQ has been split into multiple smaller documents to better categorize and allow users to find what they're looking for (in docs folder or in new website). Release summary information (versioning strategy and cadence) has been migrated from the Wiki and clarified a bit. Also adds copy button for all code snippets in website. * Copy current contributing/code of conduct to website * [docs] Creating a new generator
3.1 KiB
| id | title |
|---|---|
| debugging | Debugging |
Templates
Sometimes, you may have issues with variables in your templates. As discussed in the templating docs, we offer a variety of system properties for inspecting the models bound to templates.
-DdebugOpenAPI- Prints out the JSON model of the OpenAPI Document, as seen by OpenAPI Generator
-DdebugModels- Prints out the JSON model passed to model templates
-DdebugOperations- Prints out the JSON model passed to operation (api) templates
-DdebugSupportingFiles- Prints out the JSON model passed to supporting files
One or more of these properties can be passed alongside other command line options:
openapi-generator generate -g go \
-o out \
-i petstore-minimal.yaml \
-DdebugModels \
-DdebugOperations
Or you can add these to your JAVA_OPTS environment variable (this applies to every invocation of the tool):
export JAVA_OPTS="${JAVA_OPTS} -DdebugModels -DdebugOperations"
NOTE: Globally available system options like these will apply to all invocations of the generator (CLI and plugins)
Runtime
When you're working with a custom generator, a new generator, or otherwise trying to understand the behavior of the toolset, you may need to attach a remote debugger in order to step through the code.
The steps are shown here for a specific version of the generator, but apply the same if you're working off master or a feature branch.
- Determine the version of
openapi-generatoryou're using. For the CLI, this is:openapi-generator version - Navigate to the
openapi-generatorsource directory (see building docs for obtaining source code and brief introduction). - Checkout the branch/tag for the target version. Branches are not prefixed, but tags are prefixed with a
v. For instance if you're using version3.3.0, you will execute:git checkout v3.3.0 - Open the project in your IDE.
- Setup your IDE for remote debugging. You'll want to define a port used for connecting the remote debugger. For this example, we'll use
5005. See external tutorials for IntelliJ and Eclipse - Export the debug configuration, specifying
suspend=yso you have time to attach a remote debugger. These are passed as Java system properties, either on command line or as part of theJAVA_OPTSenvironment variable. This will look like:export JAVA_OPTS="${JAVA_OPTS} -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005" - Execute the generator with your desired options. You should see the application output only
Listening for transport dt_socket at address: 5005 - Set breakpoints in code, and then attach your remote debugger from your IDE (see above). The generator will automatically unblock once the remote debugger is attached. You can now step through the code.