Github user mlsorensen commented on the pull request:
https://github.com/apache/cloudstack/pull/1489#issuecomment-214843061
It seems complicated to try to actively promote a choice of multiple ways
to check for API authorization (dynamic vs static). I am for deprecating
commands.properties, and honestly I wish it would have been removed from the
source tree altogether long ago instead of informally deprecated, because
people have been adding to it rather than using annotations. I've spoken to
committers even recently who didn't realize that you didn't have to use
commands.properties. The annotation and dymanic methods are so much cleaner,
particularly for plugin developers as it's often the only piece of the source
tree that they have to change outside of their own plugin directory.
I don't really think the majority of users will care about the
implementation, so long as functionally the result is the same. That is to say
that the API permissions on a fresh install before and after this is merged
should behave the same out of the box. If that's the case then I don't think
users will feel forced into anything or even notice that something was changed,
and if someone really does care, it sounds simple enough to enable
commands.properties. If someone is used to fiddling with this file, they won't
have difficulty creating it and toggling a global setting manually. Speaking
from having the experience of trying to manage a custom commands.properties,
the work involved here to choose static is minor compared to simply maintaining
a custom commands.properties, making sure an upgrade doesn't overwrite your
change, and merging in new changes.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
