I have the following code:
.exec(http(“List Tasks”)
.get("/presentation//Main/portal/lists/index.cfm")
.queryParam(""“list”"", “”“tasks”"")
.check(css("#listDataTable div[id^=‘row’]").findAll.saveAs(“Tasks”))
)
.exec((s: Session) => {
println(s.getAttribute(“Tasks”))
s
})
Instead of using println to print the contents of “Tasks” to the console, can I save it to a file instead?
Is there an easy way to do this?
Thank you for your help,
–Matt Royer
Could you explain what you’re trying to achieve?
Is this for debugging purpose? Do you want to have one file per user, or only one file for all?
In the latter case, the easiest way if to have a slf4j logger into your simulation, and a dedicated appender configured in logback.xml. Do you need them for that?
Cheers,
Stéphane
Wow, that was a quick response!
Yes, it’s for debugging purposes. The information I’m pulling from our site is too big to be printed to the console (I can’t see all the information it returns).
It would just be 1 file for all. Right now I’m only testing with one user so I can get the structure of my test working. Once I get it working, I’ll scale up the users and take out the debugging info.
If you want to write your results to a file, you can use java.io classes.
1/ outside the scenario definition, create a new writer :
val writer = {
val fos = new java.io.FileOutputStream(“filename”)
new java.io.PrintWriter(fos,true)
}
You’ll have to set autoFlush to true, since you can’t properly close the PrintWriter and ensure content will be flushed to file. (and you can use import instead of fully qualified classes, of course 
)
2/ simply replace println(s.getAttribute(“Tasks”)) by writer.println(s.getAttribute(“Tasks”))
That worked perfectly! Thank you!
I’m still trying to learn Scala (and Java for that matter).
Thanks for all of your help,
–Matt Royer
You’re welcome !
I forgot to say that this solution is only fit for your use case : scenario building, 1 user, where performance does not matter too much.If you want to log some information to a file after you built your scenario and you started scaling up the users, Stephane’s solution is much better, as it won’t slow down your simulation as much as mine.
I might be wrong, but I’d tend to say that FileOutputStream is not threadsafe and you might run into issues, even with one user.
That’s the reason why I proposed an slf4j based solution that would handle concurrency for you.
val logger = org.slf4j.LoggerFactory.getLogger(“myDebugLogger”)
.exec((s: Session) => {
logger.debug(s.getAttribute(“Tasks”))
s
})
Then configure a FileAppender as described in Logback documentation:
Thank you, this is what I needed, too. This will take the place of directing periodic output to STDERR and printlns to STDOUT.
That said, I still think having the Gatling stuff going to STDERR and the scenario output going to STDOUT would be appropriate.
Errors go to stderr, those are not errors.
What we could maybe do is to have a dedicated logback logger that would go to the Console with a pattern that only prints the message.