Annotations should use behavior modification of reference objects, not as controller of logic paths witin inheritance.
@LockIdNameAttribute annotation is used to indicate incomplete logic requirement.
Each command inherit from CommandBase, and should override the getExclusiveLocks() method to acquire lock.
there is no point in having annotation for the CommandBase to call the getExclusiveLocks() or any other optional feature, as it can have its own embedded default implementations.
I would like to add that
annotations in java are not inherited .
Since we use inherience in the commands, this is a problem.
The problem exists in other commands - for example in AddDiskCommand.
Bare in mind that although the keywords, we have issues with current behavior of several commands.
This is why I acked this to 3.3.
grep "getExclusiveLocks" and extract what is missing @LockIdNameAttribute
just to make it clear, the storage commands are calling explicitly aquireLockInternal in the canDoAction. since there is no contract (no interface) we are open to mistakes and misuse. this should be rectified.
In reply to comment #3 -
Calling aquireLockInternal in CDA can still be risky, IMHO.
If we decide to postpone this from 3.3 - we should fix the above commands.
ExportRepoImageCommand has the annotation
It's also in all subclasses of RunVmCommandBase
*** Bug 997376 has been marked as a duplicate of this bug. ***
This is a bit late to get into 3.4 (2 weeks from RC) and this may be a bit riskey
Hence moving to 3.5
rhev 3.5.0 was released. closing.