On 4/8/13 11:18 AM, "Rohit Yadav" <bhais...@apache.org> wrote:
>On Mon, Apr 8, 2013 at 7:10 PM, John Burwell <jburw...@basho.com> wrote:
>
>> 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:
>>
>
>Hey John, you're right but it's a matter of code styling, I prefer
>writing;
>
>@APICommand(name = {'name1'}) even if it's only one name, this way any
>subsequent api author would know that name is an array and they can have
>aliases which is what Kishan wants.
>
>
>>
>> @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.
>>
>
>Yes, you're right we can skip the code styling I referred then it won't
>consume much coding, we just need to fix these;
>
>- Fix APICommand annotation interface definition to accept name as an
>array
>- Fix method in ApiServer which creates apiname->cmdclass map to care for
>aliases
>- Fix ApiDiscovery to take care of the aliases (create different response
>objs for the same cmd class)
>- Fix apidocs XmlWriter class to take of the aliases and the api html
>generator to process the same.
>- Fix Marvin's codegenerator.py to take care of the aliases (which means
>create apiname related modules which would contain cmd and response
>boilterplate fields/class)
>
>Cheers.
>
>
>>
>> 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.
>> >>
How about an additional attribute 'preferred' or 'deprecated' ?
@APICommand(name={'Foo', 'Bar'}, preferred='Foo', deprecated='Bar')
