- Fixed new join dao impls as spring components
- Fixed component context xml to load api rate limit checker
- Fixed root pom.xml for duplicate plugin
- Fixed list data centers method
- Fixed following conflicts:
api/src/org/apache/cloudstack/api/command/admin/network/CreateNetworkOfferingCmd.java
api/src/org/apache/cloudstack/api/command/user/offering/ListServiceOfferingsCmd.java
api/src/org/apache/cloudstack/api/command/user/template/DeleteTemplateCmd.java
api/src/org/apache/cloudstack/api/command/user/template/ExtractTemplateCmd.java
plugins/api/discovery/src/org/apache/cloudstack/discovery/ApiDiscoveryServiceImpl.java
server/src/com/cloud/api/ApiDBUtils.java
server/src/com/cloud/api/ApiServer.java
server/src/com/cloud/api/query/QueryManagerImpl.java
server/src/com/cloud/configuration/DefaultComponentLibrary.java
server/src/com/cloud/server/ManagementServerImpl.java
server/src/com/cloud/storage/swift/SwiftManagerImpl.java
Signed-off-by: Rohit Yadav <bhaisaab@apache.org>
and CloudException in one place, and Introduced ApiErrorCode to handle CloudStack API error
code to standard Http code mapping.
Signed-off-by: Min Chen <min.chen@citrix.com>
Impl. and use UserContext to get User.
CloudStack's @Inject is horrible, it may sometimes fail to inject account service
during startup. Do a lazy injection using ComponentLocator when needed.
Signed-off-by: Rohit Yadav <bhaisaab@apache.org>
- Fix method to return listApis per api name basis
- Return api response, api related cmd etc. as part of response
- Caching and processing all cmd, response classes when plugin starts, made class
list, maps static so they are shared by multiple instances in case, takes about
1306ms to do the processsing but only on load time
- Cache for first listApi() and return precached data thereon, takes 2.2ms
for first call, during runtime and 0ms thereon
Signed-off-by: Rohit Yadav <bhaisaab@apache.org>
In case of api discovery, it does not make sense to create a separate properties file
If this plugin is enabled in components.xml, a user should be able to discover
all the apis accessible to their role.
listApis based on role type of caller user
Signed-off-by: Rohit Yadav <bhaisaab@apache.org>
Remove usage and impl as adapter.
We have duplicate code that generates apiname:cmd class maps which is
unavoidable right now as:
- Plugin should not depend on ApiServer or any other component
- cloud-utils cannot depend on cloud-api for the APICommand annotation
- Use java reflect to create a static method in cloud-utils that does the job
would be unsafe.
Signed-off-by: Rohit Yadav <bhaisaab@apache.org>
- Introduces api/discovery plugin that helps discover apis on the mgmt server
- It's a pluggable service, therefore has it's own api-discovery_commands.properties
where the discovery api, listApi can be blacklisted (by removing it), or it's
role mask can be changed
- By default its response has all the apis
- Changes in other parts of the code to make it work, viz. components.xml, pom.xml,
and in ApiServer where it is used as an adapter to get apiname, cmd mappings
The ApiDiscoveryService interface is a contract that the implementing class will
provide:
1. A means to get all the apis as a list of response, plugin is free to implement
the response class, as long as it extends on the BaseResponse:
ListResponse<? extends BaseResponse> listApis();
2. Provides a map of apiname as the key and cmd class as the value:
Map<String, Class<?>> getApiNameCmdClassMapping();
Signed-off-by: Rohit Yadav <bhaisaab@apache.org>
