QueryParam Backcompat

[rpdome]

Older MSAL/Common serializes broker request request from Pair.

Even though we're ditching Pair already (for common4j - Pair is an android class), we need to be still able to support it.

[AdamBJohnsonx]

It looks like we're trying to write the most efficient form, which should abstract away the type. Before we do this, we should understand why that's not happening.

[shahzaibj]

How does this now work with new MSAL? I suppose that's going to send Map.Entry?

[rpdome]

the new MSAL (not in prod) sends Map.Entry, the old one sends Pair.

Please also read the finding i just added below - this TypeAdapter is never properly used.

[iamgusain]

We should document this in the release notes for MSAL/ADAL.. As part of how to upgrade to new major version.
right?

[shahzaibj]

I think with this change now even new one sends Pair..so I don't expect there to be any changes needed for upgrade. @rpdome can confirm.

[rpdome]

yes. no change.

[rpdome]

the new one will serialize Map.Entry into the very same format as Pair.

[iamgusain]

I had to make this change in Authenticator code, with the first RC build, that's why I thought..
Maybe I will need to revert that with the new RC build :)

[rpdome]

@AdamBJohnsonx Unfortunately, we shipped a bug from the beginning - we're supposed to specify the TypeToken of List<Pair> or List<Map.Entry> in the first parameter instead, this means that this adapter is never used, so gson has always used it default adapter from the get go.

This means we're stuck with it, unless we want to make a broker-msal protocol breaking change.

If we migrate to the right format {"eqp1":"1", "eqp2":"2"}, then it will break when MSAL is trying to talk to the older broker (which expects the pair format)

To prevent the confusion, I'll just kill the adapter.

[rpdome]

Alternatively, i could make the adapter of List<Map.Entry> to return List's format.

[shahzaibj]

@AdamBJohnsonx Unfortunately, we shipped a bug from the beginning - we're supposed to specify the TypeToken of List or List instead, this means that this adapter is never used, so gson has always used it default adapter from the get go.

This means we're stuck with it, unless we want to make a broker-msal protocol breaking change.

If we migrate to the right format {"eqp1":"1", "eqp2":"2"}, then it will break when MSAL is trying to talk to the older broker (which expects the pair format)

To prevent the confusion, I'll just kill the adapter.

What does GSON default adapter do? I suppose it is handling Pair correctly? Can the default not handle Map.Entry?

[rpdome]

@AdamBJohnsonx Unfortunately, we shipped a bug from the beginning - we're supposed to specify the TypeToken of List or List instead, this means that this adapter is never used, so gson has always used it default adapter from the get go.
This means we're stuck with it, unless we want to make a broker-msal protocol breaking change.
If we migrate to the right format {"eqp1":"1", "eqp2":"2"}, then it will break when MSAL is trying to talk to the older broker (which expects the pair format)
To prevent the confusion, I'll just kill the adapter.

What does GSON default adapter do? I suppose it is handling Pair correctly? Can the default not handle Map.Entry?

you get something like this

pair: [{"first":"eqp1","second":"1"},{"first":"eqp2","second":"2"}]
map: [{"key":"eqp1","value":"1"},{"key":"eqp2","value":"2"}]

The default can handle map, but we're stuck with the pair format (since there will always be older MSAL sending it, or an older Broker that expects it)

[AdamBJohnsonx]

Alternatively, i could make the adapter of List<Map.Entry> to return List's format.

Bleah. So the thing you *can * do is to code the read side of this adapter so that it can understand any of these formats, rev the broker protocol version for the compact format, and choose how you want to send it. We should definitely break any tie between the structure of code being used to hold the data and how that data is transmitted and understood, however it happens.

[shahzaibj]

Looks good to me.