To avoid confusion, I removed the entityType field from the particular
param in deployvmcmd. Pl. read the commit message, for MAP type params
it's always processed a map of string,string and the processing should
be done by an api writer at cmd class level and it's not done in
ApiDispatcher.
commit 66430c97457041b87bfbaddad6955a77a42ffdee
Author: Rohit Yadav <bhais...@apache.org>
Date: Mon Jan 28 15:43:37 2013 -0800
DeployVMCmd: Remove entityType for ipToNetworkList, MAP is string->string
Remove entityType as it can confuse people, right now we process
map to string
data type maps<string,string> This map should be handled in cmd
class level by
an api writer to getObject by uuid or by long int id as in
getIpToNetworkMap()
of DeployVMCmd
Signed-off-by: Rohit Yadav <bhais...@apache.org>
Regards.
On Mon, Jan 28, 2013 at 2:32 PM, Rohit Yadav <bhais...@apache.org> wrote:
> On Sun, Jan 27, 2013 at 8:37 PM, Kelven Yang <kelven.y...@citrix.com> wrote:
>> I have a question about a change in @Parameter at API layer, in regards to
>> entityType, does anyone know the reason behind why it has to go through
>> with some Response class which in turn declares links to the entity class
>> via @EntityReference annotation?
>>
>> And in DeployVMCmd as an example, there is also another special field
>> (ipToNetworkList) declares entity reference directly, could someone
>> clarify it?
>>
>> @ACL(checkKeyAccess=true)
>> @Parameter(name = ApiConstants.IP_NETWORK_LIST, type =
>> CommandType.MAP, entityType={Network.class, IpAddress.class},
>> description = "ip to network mapping. Can't be specified with
>> networkIds parameter." +
>> " Example:
>> iptonetworklist[0].ip=10.10.10.11&iptonetworklist[0].networkid=uuid -
>> requests to use ip 10.10.10.11 in network id=uuid")
>> private Map ipToNetworkList;
>
> Coming straight to the issue, if a parameter type is MAP, right now
> the present annotation is insufficient to help ApiDispatcher process a
> parameter which is of map type, so we just set the map as it is (i.e.
> a string);
>
> case MAP:
> default:
> field.set(cmdObj, paramObj);
> break;
>
> The ipToNetworkList of DeployVMCmd, is the only variable I found in
> all apis which has this issue. So, in getIpToNetworkMap() we first try
> to find a Network object using a network string value from the map's
> "networkid" keyset and if we fail we try to parse long value. This
> make the param backward compatible as well as accept both uuid and
> ids. We can work on better ways to deal with maps in future.
> Regards.
>
>>
>> Kelven
>>
>>
