OlegChuev opened a new pull request, #14624: URL: https://github.com/apache/cloudstack/pull/14624
### Description This PR fixes a `NullPointerException` in the site-to-site VPN list APIs (`listVpnCustomerGateways`, `listVpnGateways`, `listVpnConnections`) and in the autoscale list APIs that share `AutoScaleManagerImpl.SearchWrapper` (`listAutoScaleVmProfiles`, `listAutoScalePolicies`, `listAutoScaleVmGroups`, `listConditions`) when the page size is unlimited. `BaseListCmd.getPageSizeVal()` and `BaseListCmd.getStartIndex()` return `null` when the page size is unlimited, that is when the global setting `default.page.size` is `-1` and the caller sends no `pagesize`, or when the caller sends `pagesize=-1`. `Site2SiteVpnManagerImpl.searchForCustomerGateways`, `searchForVpnGateways`, `searchForVpnConnections` and `AutoScaleManagerImpl.SearchWrapper` stored both values in primitive `long` variables, so the auto-unboxing threw before the query ran: ``` Cannot invoke "java.lang.Long.longValue()" because the return value of "org.apache.cloudstack.api.command.user.vpn.ListVpnConnectionsCmd.getStartIndex()" is null ``` The fix keeps both values as `Long` and passes them to `Filter(Class, String, boolean, Long, Long)` as the other list APIs already do; a `null` offset and limit mean "no paging", so these APIs now return every matching row, like the rest of the list APIs do with an unlimited page size. Expected behaviour: with an unlimited page size, `listVpnConnections` (and the other APIs above) return all matching items. Actual behaviour: the API fails with status 530 and the NPE above. Steps to reproduce: 1. Set the global setting `default.page.size` to `-1`. 2. Restart the management server. 3. Call `listVpnConnections` (or `listVpnGateways`, `listVpnCustomerGateways`, `listAutoScaleVmGroups`, ...) without `pagesize`. Calling them with `pagesize=-1` on any setup reproduces it too. The same kind of unboxing still exists in a few other places that this PR does not change, as they need more than a type change: - `QueryManagerImpl.listSecurityGroupRulesByVM(long vmId, long pageInd, long pageSize)` — `listSecurityGroups` with `virtualmachineid` and an unlimited page size. - `ManagementServerImpl.listTopConsumedResources` — `cmd.getPageSizeVal().toString()` and `summedCapacities.size() < cmd.getPageSizeVal()` (`listCapacity` with `sortby`). - `StorageBrowserImpl` — `cmd.getStartIndex().intValue()` / `cmd.getPageSizeVal().intValue()` (`listImageStoreObjects`, `listStoragePoolObjects`); the agent command needs integer paging. ### Types of changes - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] New feature (non-breaking change which adds functionality) - [x] Bug fix (non-breaking change which fixes an issue) - [ ] Enhancement (improves an existing feature and functionality) - [ ] Cleanup (Code refactoring and cleanup, that may add test cases) - [ ] build/CI - [ ] test (unit or integration test code) ### Feature/Enhancement Scale or Bug Severity #### Feature/Enhancement Scale - [ ] Major - [ ] Minor #### Bug Severity - [ ] BLOCKER - [ ] Critical - [x] Major - [ ] Minor - [ ] Trivial ### Screenshots (if appropriate): ### How Has This Been Tested? Added `Site2SiteVpnManagerImplTest` with one test per VPN list method: the command returns `null` for `getStartIndex()` and `getPageSizeVal()` (as `BaseListCmd` does for an unlimited page size), and the test checks that the search runs and the `Filter` passed to the DAO has a `null` offset and limit. Added `AutoScaleManagerImplTest.testListConditionsWithUnlimitedPageSize`, which does the same for `listConditions` and so covers `SearchWrapper`. Without the fix all four tests fail with the NPE; with it they pass, along with the rest of `AutoScaleManagerImplTest`, and checkstyle reports no violations. ``` mvn -pl server test -Dtest='Site2SiteVpnManagerImplTest,AutoScaleManagerImplTest' ``` #### How did you try to break this feature and the system with this change? With a finite page size `getStartIndex()` and `getPageSizeVal()` are never `null`, and the `Filter` receives the same values as before, so paging behaviour is unchanged for existing setups. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
