[Scala][Gatling] correct body params filename

[atomfrede]

PR checklist

• Read the contribution guidelines.
• Ran the shell script under ./bin/ to update Petstore sample so that CIs can verify the change. (For instance, only need to run ./bin/{LANG}-petstore.sh and ./bin/security/{LANG}-petstore.sh if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in .\bin\windows\.
• Filed the PR against the correct branch: 3.0.0 branch for changes related to OpenAPI spec 3.0. Default: master.
• Copied the technical committee to review the pull request if your PR is targeting a particular programming language.

@clasnake @jimschubert @shijinkui

Description of the PR

The -BodyParams.csv file must be named -bodyParams.csv as that file is used in the gatling test defnition. Futhermore all other files are also using lowercase names (e.g. -headerParams.csv).

close #7616

[wing328]

@atomfrede thanks for the PR.

cc @andavis84 for review.

[atomfrede]

@wing328 The sample files are supposed to be commited too, right?

[jimschubert]

Is this issue platform it environment specific? Like would the previous work only on Windows, or in shells with opts enabled for case insensitive filename matching?

I agree with the fix, just wondering why it would work for some and not others.

[atomfrede]

I stumbled across that using linux, didn't tried it on windows.

[jimschubert]

I was wondering because I ran the original in my old Mac with HFS+ filesystem. My new Mac is APFS, which I believe is also case insensitive but case preserving. I've had issues with changing filename casing for files stored in git, but never had case issues with tools like this.

When I have a chance this weekend, I'll run again locally and then within an Alpine docker image with Scala and report back here if I find differences. It would be a good point for reviewers to double check filename case sensitivity.

[jimschubert]

I tested this out a bit, and I couldn't reproduce the behavior I remembered seeing from my review of the initial generator. I ran each time with gradle gatlingRun.

So I looked at how Gatling defines a classpath resource:

private object ClasspathResource {
    def unapply(location: Location): Option[Validation[Resource]] =
      Option(getClass.getClassLoader.getResource(location.path.replace('\\', '/'))).map { url =>
        url.getProtocol match {
          case "file" => FileResource(url.jfile).success
          case "jar"  => ArchiveResource(url).success
          case _      => s"$url is neither a file nor a jar".failure
        }
      }
}

And I tested this logic locally with a file under resources and named in all lowercase as a.txt. Passing A.txt causes the extractor to fail as expected-- I'd expect the JVM to be case sensitive for resources. Shell commands, however, consider the filename case insensitively:

$ ls
a.txt
$ cat a.txt
Hello, World!
$ cat A.txt
Hello, World!

Which is expected on the case insensitive APFS variant file system.

I'm wondering if it's possible that I ran gatling via gradle in some way that used file based resolution rather than classpath? I'm not that familiar with Gatling to even recall how I ran it previously. I tested this out using a FileInputStream which is what's used in Gatling, and with the same lowercase filename, the following reads the contents when passed as A.txt:

import java.io._
import scala.io._

object Main extends App {
  val file = new File("/path/to/src/main/resources/A.txt")
  val contents = Source.fromInputStream(new FileInputStream(file)).mkString
  println(contents)
}

Obviously this is to be expected because my file system is case insensitive. It's just somewhat weird that in Gatling I could potentially succeed on a case insensitive file system in one path of execution but fail when the same file is loaded via classpath.

Anyway, the fix in this PR is obviously the way to go for consistency.