Getting session attribute as String returns Integer

Gatling (Open-Source)
1

Hey all, so I’m encountering some very odd behavior…

So I have a session attribute “foo” which is paired with an Integer, 1:

session.set(“foo”, 1)

session(“foo”).as[String] returns ‘1’ (but it’s an Integer)
session(“foo”).as[String].getClass returns ‘class java.lang.Integer’
session(“foo”).as[String].toString throws an exception, saying java.lang.Integer cannot be cast to java.lang.String

session(“foo”).as[Int].toString returns the expected integer as a string.

… What’s going on?

Am I crazy or is this working as intended?

2

TBH, there is nothing really unexpected, when you know that:

  • as[T] boils down to a simple cast

  • the session attributes are stored in a Map[String, Any], therefore type information for values is lost
    See the details below.

Whenever possible, prefer validate[T] to as[T] : incorrect type casts, missing values… are handled automatically through the use of Gatling’s Validation[T] type.

Cheers,

Pierre

Hey all, so I’m encountering some very odd behavior…

So I have a session attribute “foo” which is paired with an Integer, 1:

session.set(“foo”, 1)

session(“foo”).as[String] returns ‘1’ (but it’s an Integer)

As long as you don’t try to use it (case 3), the cast may work.

session(“foo”).as[String].getClass returns ‘class java.lang.Integer’

Nothing unexpected, the runtime class is indeed an Integer, even you tried to cast it as a String.

session(“foo”).as[String].toString throws an exception, saying java.lang.Integer cannot be cast to java.lang.String

This time you’re using the value and it fails.

session(“foo”).as[Int].toString returns the expected integer as a string.

This is probably what you really wanted :slight_smile:

3

Ha ha ha!

No, you’re not crazy. Type erasure FTL…

I already fixed the behavior for asOption a few days ago: https://github.com/gatling/gatling/issues/2712

I’m still considering if we should enforce the same behavior for “as”.
In a sense, such validation introduces some overhead.

4

Ok, so at least it’s expected. I guess I was just surprised I hadn’t encountered it before now! I’m also surprised that Integer.asInstanceOf[String] doesn’t automatically call .toString.

And I feel like that behavior is definitely useful in an Option, where you have two layers of indirection: The Option type and then the generic value type. In any case, it’s a simple fix for now. I haven’t set up my project to use Validations in any more useful way then Options yet, so it’s a to-do.

Thanks again for the useful explanations Stéphane and Pierre!

5

Ok, so at least it’s expected. I guess I was just surprised I hadn’t encountered it before now! I’m also surprised that Integer.asInstanceOf[String] doesn’t automatically call .toString.

There is no reason to call toString: after all, what you asking for is a class cast not a ‘conversion’ :wink:

And I feel like that behavior is definitely useful in an Option, where you have two layers of indirection: The Option type and then the generic value type. In any case, it’s a simple fix for now. I haven’t set up my project to use Validations in any more useful way then Options yet, so it’s a to-do.

Thanks again for the useful explanations Stéphane and Pierre!

You’re welcome :slight_smile: