Best way to get random value from a Seq[String] in session?

Hi,

I’ve been thinking about some methods to get a random value of a list of data (Seq) stored in Session.
The way I get the into the session is quite easy:

http(“GET: /actors”)
.get("/actors")
.headers(Configuration.http.defaultHeader)
.check(
status.is(200),
jsonPath("/actor/id").findAll.saveAs(“actor-list”))

Getting it out during build time is also not that hard:

repeat(count, “index”) {
exec(
http(“POST: /play”)
// …
.fileBody(“play-template”, Map(
“actor_id” → “${actor-list(index)}”))
// …
}

But getting it out during runtime if “index” would be a random variable based on the size of the list … I got not really a clue.
The most common problem about this, is that a fileBody-Method can only be gotten a Map[String,String] but not Map[String,EvaluatableString]

  1. I was thinking about some kind of session function calc a random variable and put it into the session “index”
    So I would always need to add this function before - looks like

repeat(count, “index”) {
exec(addRandomSessionValueBasedOnList(“actor-list”, “foobar”))
exec(
http(“POST: /play”)
// …
.fileBody(“play-template”, Map(
“actor_id” → “${actor-list(foobar)}”))
// …
}

  1. I was also thinking about some kind of SessionFeeder who can get the necessary value from session
    (no idea to implement this, maybe this idea isn’t that good)

  2. Another way would be widening the fileBody-Method interface to handle Map[String,EvaluatableString]
    (as I can see in source code the parameter Map[String,String] is later transfered into Map[String,EvaluatableString])

  3. Going in hand with (3.) there is the idea to extend the EL handling lists easier (e.g. “${actor-list}.random”).

Have You other/better suggestions?

Regards Danny

1. The standard way to go:
val random = new java.util.Random (you can use ThreadLocalRandom is JDK7
works fine for you)

exec(session =>
   val list = session.getTypedAttribute[Seq[String]]("actor-list")
   session.setAttribute("foobar", list(random.nextInt(list.size))
)

2. Shouldn't do that, feeders' scope is shared, not user-specific, at least
for now
3. Definitely! We slipped this one.
4. Yep, could do.

I'll open issues for 3 and 4.
3 will be in 1.4 but 4 might have to wait for 2.0.

Stéphane