Yes, that is unfortunate design. The service interface was not supposed to do that. CC Min and Alex to see if they have a quick workaround. It would also help to know what exactly you are trying to achieve.
On 7/15/13 11:12 PM, "SuichII, Christopher" <chris.su...@netapp.com> wrote: >It looks like the service interfaces all expect to be invoked directly >from an API handler (they only have Cmds for parameters). For example, >QueryService/QueryManagerImpl.searchForServers() takes a ListHostsCmd. >This ListsHostsCmd can only be created by invoking the listHosts API. If >it had public setters, then the command could be instantiated and >execute() could be called directly, but that wouldn't be working at the >service interface level. > >Am I missing something here or is this not the service interface you >meant? > >-Chris > >On Jul 15, 2013, at 12:29 AM, Chiradeep Vittal ><chiradeep.vit...@citrix.com> wrote: > >> APIs should call the service interface directly and not call other APIs. >> >> On 7/12/13 1:40 AM, "SuichII, Christopher" <chris.su...@netapp.com> >>wrote: >> >>> Er, I should have mentioned that it is not as easy as simply invoking >>>one >>> API command from another since all the CS API commands have private >>> @paramenter members. Because of this, I cannot simply instantiate a >>> command, populate it with the parameters and call execute() on it. >>> >>> -Chris >>> >>> On Jul 11, 2013, at 4:09 PM, Chris Suich <chris.su...@netapp.com> >>> wrote: >>> >>>> I'm writing an API plugin that needs to consume an API that already >>>> exists in CS. The only way I can find to do this would be to send the >>>> REST/HTTP request from my plugin, but I'm hoping there is an easier >>>>way. >>>> Since both plugins are on the same Java classpath they have the >>>>ability >>>> to invoke each other. >>>> >>>> Is there a simple way to do this that I'm missing? >>>> >>>> -Chris >>> >> >
