Getting session attribute as String returns Integer

[Andrew Krischer]

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?

[Pierre DAL-PRA]

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 

On Thursday, 14 May 2015 17:39:24 UTC+2, Andrew Krischer wrote:

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 :)

[Stéphane LANDELLE]

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.

Stéphane Landelle

Lead developer

slan...@gatling.io

--
You received this message because you are subscribed to the Google Groups "Gatling User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gatling+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andrew Krischer]

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!

[Pierre DAL-PRA]

On Thursday, 14 May 2015 19:27:53 UTC+2, Andrew Krischer wrote:

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' ;)

 

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 :)