Rohit,
Why would we need to rewrite any Java code to switch to an array? As I
mentioned, array annotation values are treated as varargs. Therefore,
annotations with single values can be left alone. Only cases where multiple
values are required would require the addition of curly braces. For example,
for an APICommand with one name, the following would continue to work:
@APICommand(name="apiName1")
While for an APICommand with multiple names, the following form would now be
supported:
@APICommand(name={"apiName1", "apiName2", "apiName3"})
I am not familiar with the Marvin code, so I can not speak to the impact of
this change to it. However, the only changes to the Java code should be the
API commands with multiple names and the classes that actually consume the
value of this annotation.
Thanks,
-John
On Apr 8, 2013, at 9:22 AM, Rohit Yadav <bhais...@apache.org> wrote:
> On Mon, Apr 8, 2013 at 6:33 PM, Kishan Kavala <kishan.kav...@citrix.com>wrote:
>
>> APICommand annotation in API Cmd object has a name parameter. Currently
>> name parameter takes only one value. I plan to enhance this to support
>> comma separated values. This will allow multiple API names for the same API
>> Cmd object.
>>
>> Current:
>> @APICommand(name = "apiName1", ..
>>
>> Proposed:
>> @APICommand(name = "apiName1, apiAlias2, apiAlias3", ..
>>
>
> It's a hack, but doable. While not elegant as John suggests, parsing comma
> separated value can lead to some issues.
>
> Changing the name field to array would require a lot of rewriting the
> present apis annotation name fields, again doable by a small python program
> (like the one I used in the last name field refactoring).
>
> This would really help remove duplicate cmd classes for apis such as copy
> iso and volume which does the same job but requires two different cmd class
> implementations.
>
> Whatever way you decide, pl. make sure to fix ApiDiscovery, ApiServer
> cmdclass-apiname map generator method and apidocs generation accordingly.
>
> Cheers.
>
>
>>
>> Requirement:
>> As part of CLOUDSTACK-763, I'll be introducing NetworkACLList (grouping of
>> NetworkACLItems). Current APIs use *NetworkACL (create
>> NetworkACL/deleteNetworkACL etc..) for NetworkACLItem related APIs. These
>> APIs have to be changed to *NetworkACL Item(create
>> NetworkACLItem/deleteNetworkACLItem etc..) to get the terminology right. We
>> also need to support old API names for backward compatibility. Hence the
>> need for API name alias.
>>
>> Terminology:
>> NetworkACLItem - Individual ACL Entry (was NetworlACL earlier).
>> NetworkACL - Group of Network ACL Items. API will use the term
>> NetworkACLList to differentiate from the existing NetworkACL APIs.
>>
>>
>>
