Introduction of a new Transaction API that is more consistent with the style
of Spring's transaction managment. The existing Transaction class was renamed
to TransactionLegacy. All of the non-DAO code in the management server has been
updated to use the new Transaction API.
- code comment turned to javadoc
- added braces to if and for statements to make it look more like the rest
- tests added
Signed-off-by: Laszlo Hornyak <laszlo.hornyak@gmail.com>
- javadoc changed - the old one was copy-pasted from AgentShell
- start and stop method removed - they did the same as the overridden methods
- _counter removed as it was only written, but never read
- remove from _asleep map was moved to a finally block, to make sure it is removed even in case of the thread gets interrupted
- Tests created for the above scenarios.
Signed-off-by: Laszlo Hornyak <laszlo.hornyak@gmail.com>
- removed methods that were not used
- parseLong, parseInt and parseFloat replaced with the commons-lang NumberUtils call
- Test for the remaining methods
Signed-off-by: Laszlo Hornyak <laszlo.hornyak@gmail.com>
Signed-off-by: Hugo Trippaers <htrippaers@schubergphilis.com>
As we moved to a more Spring managed lifecycle, the lifecycle management
in ComponentContext is not needed. The transition to fully spring managed
will not happen all at once. The management server will be done first and
then AWSAPI and UsageServer will come later. This change allows the
ComponentContext in the context of the management server to be bypassed.
Note, by default, the ComponentContext will run its initialization.
It was implemented by extending the NFS provider. Its validation was updated so that you can pass it a URL containing the
details of a CIFS share. The code that mounts NFS shares was extended to allow it do the same for CIFS shares. Otherwise,
the secondary storage code is left unchanged.
After upgrade the SSVM was staying in connecting/alert state. This was because
while handling the processConnect command for ssvm the management server was
trying to template sync. For resource limit calculation it was trying to get the
remote size of the template. If the template was no longer available a number
format exception was thrown. The process connect wasn't getting completed and
the ssvm used to stay in connecting/alert state. While creating template from
snapshot cloudstack looks for up and enabled ssvms and because there wasn't
any available (as the ssvm was in coonecting/alert state) it used to pick the
wrong resource (LocalNfs*Resource) instead of the NfsSecondaryStorageResource.
Fixed the issue by making sure number format exceptions are avoided so that
SSVM moves to the right state.
No change in behavior if management server has internet connection.
Now if management server doesn't have internet connection download process will not fail. But CS will noly check if the account has already reached or maxed its limits instead of checking if the limit will be breached with the addition of the new storage