I'm using Mustache with swagger-codegen to generate model-entities from definitions, and code from operations (paths section). Each operation specifies a list of parameters, and other parameter attributes - datatype, description, default-value, required, maximum, example, etc.
I cannot work out how to access any parameter property besides the 'required' attribute ... except in the 'model' phase ... how can I do this in the 'api' phase ? ... I'd like to be able to drop code that verifies that the parameters meet conditions beyond 'required', like min/max, etc.
you have some options for accessing parameter properties.
First off, I assume you're using swagger-codegen 2.1.0-M2 or a later snapshot. There are a number of properties available for each parameter, but they are currently not quite as rich as in the model properties.
To see what you have access to, please run the codegen with debug flags, which will print out all the information available to you in the templates:
java -DdebugOperations -jar swagger-codegen-cli.jar \
generate \
-i http://petstore.swagger.io/v2/swagger.json \
-l java \
-o samples/client/petstore/java
The other debug flags are:
# print out the interpreted swagger spec
-DdebugSwagger
# print out model info
-DdebugModels
# print out supporting file data
-DdebugSupportingFiles
Related
I want to create some "build traceability" functionality, and include the actual bazel command that was run to produce one of my build artifacts. So if the user did this:
bazel run //foo/bar:baz --config=blah
I want to actually get the string "bazel run //foo/bar:baz --config=blah" and write that to a file during the build. Is this possible?
Stamping is the "correct" way to get information like that into a Bazel build. Note the implications around caching though. You could also just write a wrapper script that puts the command line into a file or environment variable. Details of each approach below.
I can think of three ways to get the information you want via stamping, each with differing tradeoffs.
First way: Hijack --embed_label. This shows up in the BUILD_EMBED_LABEL stamping key. You'd add a line like build:blah --embed_label blah in your .bazelrc. This is easy, but that label is often used for things like release_50, which you might want to preserve.
Second way: hijack the hostname or username. These show up in the BUILD_HOST and BUILD_USER stamping keys. On Linux, you can write a shell script at tools/bazel which will automatically be used to wrap bazel invocations. In that shell script, you can use unshare --uts --map-root-user, which will work if the machine is set up to enable bazel's sandboxing. Inside that new namespace, you can easily change the hostname and then exec the real bazel binary, like the default /usr/bin/bazel shell script does. That shell script has full access to the command line, so it can encode any information you want.
Third way: put it into an environment variable and have a custom --workspace_status_command that extracts it into a stamping key. Add a line like build:blah --action_env=MY_BUILD_STYLE=blah to your .bazelrc, and then do echo STABLE_MY_BUILD_STYLE ${MY_BUILD_STYLE} in your workspace status script. If you want the full command line, you could have a tools/bazel wrapper script put that into an environment variable, and then use build --action_env=MY_BUILD_STYLE to preserve the value and pass it to all the actions.
Once you pick a stamping key to use, src/test/shell/integration/stamping_test.sh in the Bazel source tree is a good example of writing stamp information to a file. Something like this:
genrule(
name = "stamped",
outs = ["stamped.txt"],
cmd = "grep BUILD_EMBED_LABEL bazel-out/volatile-status.txt | cut -d ' ' -f 2 >\$#",
stamp = True,
)
If you want to do it without stamping, just write the information to a file in the source tree in a tools/bazel wrapper. You'd want to put that file in your .gitignore, of course. echo "$#" > cli_args is all it takes to dump them to a file, and then you can use that as a source file like normal in your build. This approach is simplest, but interacts the most poorly with Bazel's caching, because everything that depends on that file will be rebuilt every time with no way to control it.
In JMeter 5.2.1, by default I have response with embedded resources in abstract format like that:
domain/path
domain/path-0
domain/path-1
domain/path-2
domain/path-3
...
(etc.)
I need to see normal URLs to each embedded resource instead of these abstract suffixes with -0,-1,-2,-3 etc. (like it worked in JMeter v.3).
How is it possible to set up, to have embedded resources in format of full URLs for each embedded resource?
Could you please give me a tip or lifehack for that for JMeter v.5+?
If this is something you really need, you can add the next line to user.properties file (it lives under "bin" folder of your JMeter installation):
subresults.disable_renaming=true
For one-time usage the property can be overridden via -J command-line argument like:
jmeter -Jsubresults.disable_renaming=true -n -t test.jmx -l result.jtl
Check out Apache JMeter Properties Customization Guide article for more information on JMeter properties and ways of setting/overriding them. You might also be interested in Settings that affect SampleResults chapter of JMeter Properties Reference
However you should be doing this only if you plan to use JMeter for some form of functional testing because it will break the logic of HTTP Request sampler elapsed time calculation in the HTML Reporting Dashboard
I'm using grails 3.2.6. I'm writing a custom grails command. It's a command and not a script because I need access to object in the spring application context in the command. I would like for my command to accept command line arguments with values such as "name" and "group" and "id". For example, I'd like to be able to run the command like this:
grails run-command process-group --name=foo --group=bar --id=2
However, when I do this, my command implementation class doesn't seem to have access to any of these arguments (name, group, or id). I've tried accessing them through the args attribute that comes from the GrailsApplicationCommand trait, but that is empty. I've also tried accessing it through various methods of the CommandLine object that is accessible through executionContext.commandLine object which also comes from the GrailsApplicationCommand trait. However, everything there seems to be empty as well (undeclaredOptions is empty, remainingArgs is empty, rawArguments just has my command name which is "process-group", etc.). If I remove the leading "--" from my argument names like this:
grails run-command process-group name=foo group=bar id=2
then the args attribute contains 3 entries: ["name=foo", "group=bar", and "id=2"]. I suppose that I could implement my command this way (no leading "--" on the command arguments), but it's kind of ugly, and it also means that I have to parse the arguments myself. The grails docs (http://docs.grails.org/latest/guide/single.html#creatingCustomCommands) say that, "Since Grails 3.2.0, commands have similar abilities as scripts in regards to retrieving arguments, template generation, file access, and model building." I'm interested in the retrieving arguments part of that statement. The examples shown in the documentation for scripts (not commands) show (http://docs.grails.org/latest/guide/single.html#creatingCustomScripts) how to declare parameters that a script will take from the command line. For example, this command line is supposed to work with a custom script that declares the "force" parameter for the generate-all custom script:
grails generate-all MyClass --force
This all seems to be tied to the use of the description() method in the script:
description( "Generates a controller that performs CRUD operations and the associated views" ) {
usage "grails generate-all <<DOMAIN CLASS>>"
flag name:'force', description:"Whether to overwrite existing files"
argument name:'Domain Class', description:'The name of the domain class'
}
However, there doesn't seem to be a description() method available for use for custom commands as there is for custom scripts. I just confused about how the grails docs state that retrieving arguments is supposed to now work the same for both custom scripts and custom commands, yet I can't seem to retrieve arguments from a custom command like I can from a custom script. Is there a way that I can retrieve the arguments for a custom command just like it can be done for a custom script?
Set the properties using the -D option:
-Dsample.message=foo
Grab the system properties using the follow code:
System.properties['sample.message']
Link to the where I found this example:
Passing Properties
As you can see in the screenshots, I am setting some user defined variables using 2 byte characters. I'm submitting the HTTP request to create this customer using UTF-8 encoding. The customer is being created with the correct double byte character characters because I can see them in the web app and in the DB. The problem is that I cannot see them in jmeter. It either shows little boxes or ??? question marks instead of the characters in the response data and in the debug sampler. The User defined variables is showing the characters correctly. I've added this to my user.properties file but that did not help:
sampleresult.default.encoding=UTF-8
How can I see these special characters in the response so I can Assert the record was created correctly? Any advice is appreciated. I am using jmeter 3.1 and JSON endpoints.
User Defined variables
DebugSampler
Now you need to ensure that JMeter itself is using UTF-8 encoding.
Configure Debug Sampler to show System Properties
Look for file.endoding property
If you see something different - override the existing property value using one of the following ways:
Permanent: add the next line to system.properties file (in JMeter's "bin" folder)
file.encoding=UTF-8
JMeter restart will be required to pick the property up
Temporary: set the "file.encoding" property via -D command-line argument as
jmeter -Dfile.encoding=UTF-8 -n -t ....
References:
Java - Supported Encodings
Apache JMeter Properties Customization Guide
I'm currently setting up Fitnesse, with FitSharp and the .net implementation of dbfit.
I understand how to trigger tests or suites from the submission of a URL, or from a command line, eg:
java -jar fitnesse-standalone.jar -c "MyTest?test&format=text"
What I can't figure out is how to submit variable values in this query string.
So, if I have a test containing a Sql statement which has a Fitnesse variable referenced in the Where clause, and the value of this variable is defined in a sibling static page, I would like to be able to run this test from the command line and submit a value for this variable which overrides the value in the static page. Something like:
java -jar fitnesse-standalone.jar -c "MyTest?test&format=text&${myVar}=abc"
Is this possible at all?
Thanks
Mark
There are two ways to pass variables from the command line, both involving environment variables.
(1) Define an environment variable (or identify one that already exists). You can use general purpose system variables (like %TMP% or %HOMEPATH%) or your own user-defined variables (e.g. %JAVA_HOME%) or create your own. My short Fitnesse launcher (a .CMD file) is this:
set SEED=%RANDOM%
set FITNESSE_PORT=9999
java -jar fitnesse-standalone.jar -p %FITNESSE_PORT% -e 0
The FITNESSE_PORT variable is defined just for use in the very next line. The SEED variable, however, does magic: it allows several people to run the same test simultaneously by generating unique values per session. (This assumes that each user runs their own FitNesse server, so each will thereby have a unique session.) I then instrument my tests by defining ids relative to the seed, e.g.
!define TestClient (MyTestClient_${SEED})
(2) Pass an environment variable setting scoped to just the java process that instantiates the FitNesse runner. This technique gives you precisely the same results with just a different implementation:
java -DSEED=%RANDOM% -jar fitnesse-standalone.jar -p %FITNESSE_PORT% -e 0
This yields precisely the same result within FitNesse, giving you access to the %SEED% environment variable as ${SEED}.
For more, see part 2 of my seven-part series on Acceptance Testing with FitNesse published on Simple-Talk.com.