Bug 995836 - [command] remove the use of @LockIdNameAttribute
[command] remove the use of @LockIdNameAttribute
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
unspecified
Unspecified Unspecified
unspecified Severity medium
: ---
: 3.5.0
Assigned To: Ravi Nori
Martin Mucha
infra
: CodeChange
: 997376 (view as bug list)
Depends On:
Blocks: 997376 rhev3.5beta 1156165
  Show dependency treegraph
 
Reported: 2013-08-11 08:08 EDT by Alon Bar-Lev
Modified: 2016-02-10 14:38 EST (History)
10 users (show)

See Also:
Fixed In Version: vt1.3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 997376 (view as bug list)
Environment:
Last Closed: 2015-02-17 12:15:06 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 25944 master MERGED engine: remove the use of @LockIdNameAttribute Never
oVirt gerrit 25964 None ABANDONED engine: remove the use of @LockIdNameAttribute Never

  None (edit)
Description Alon Bar-Lev 2013-08-11 08:08:15 EDT
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.
Comment 1 Yair Zaslavsky 2013-08-11 09:14:31 EDT
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.
Comment 2 Yair Zaslavsky 2013-08-11 09:18:48 EDT
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.
Comment 3 Roy Golan 2013-08-11 10:04:49 EDT
grep "getExclusiveLocks" and extract what is missing @LockIdNameAttribute


bll/src/main/java/org/ovirt/engine/core/bll/AddDiskCommand.java
bll/src/main/java/org/ovirt/engine/core/bll/MoveOrCopyDiskCommand.java
bll/src/main/java/org/ovirt/engine/core/bll/RunVmCommandBase.java
bll/src/main/java/org/ovirt/engine/core/bll/AddVdsCommand.java
bll/src/main/java/org/ovirt/engine/core/bll/UpdateVmTemplateCommand.java
bll/src/main/java/org/ovirt/engine/core/bll/ExportRepoImageCommand.java
Comment 4 Roy Golan 2013-08-11 10:12:35 EDT
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.
Comment 5 Yair Zaslavsky 2013-08-12 08:22:09 EDT
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.
Comment 7 Yair Zaslavsky 2013-08-19 10:12:49 EDT
ExportRepoImageCommand has the annotation
Comment 8 Yair Zaslavsky 2013-08-19 10:16:16 EDT
It's also in all subclasses of RunVmCommandBase
Comment 9 Eli Mesika 2013-11-08 03:28:55 EST
*** Bug 997376 has been marked as a duplicate of this bug. ***
Comment 11 Barak 2014-04-10 12:47:31 EDT
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
Comment 12 Eyal Edri 2015-02-17 12:15:06 EST
rhev 3.5.0 was released. closing.

Note You need to log in before you can comment on or make changes to this bug.