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.
> >>
> >>
> >>
>
>
