Good job.
In general, we have a uutils module for utils that can serve other projects, not just
engine (i.e - we can have a separate artifact that does not depend on common for
example).
IMHO, 2 is a good candidate to go to uutils.
Yair
----- Original Message -----
From: "Mike Kolesnik" <mkolesni(a)redhat.com>
To: devel(a)ovirt.org
Sent: Sunday, July 13, 2014 9:15:06 PM
Subject: [ovirt-devel] Removing boilerplate code in engine
Hi,
I recently introduced 2 changes for removing boilerplate code:
1.
http://gerrit.ovirt.org/29414 - Fluent syntax for writing validations
2.
http://gerrit.ovirt.org/29617 - Wrapper for locks to use with
try-with-resources
By removing boilerplate code we're making the code less error prone and
easier to read (and maintain).
I've already sent some simple refactors to use these new styles of writing,
but more work is necessary to apply to the whole project.
I urge all engine developers that need to write such code to use the new
styles of writing.
Below are examples for each change.
1. When expecting a negative outcome, instead of using:
return getVds() == null
? new
ValidationResult(VdcBllMessages.ACTION_TYPE_FAILED_HOST_NOT_EXIST)
: ValidationResult.VALID;
use:
return
ValidationResult.failWith(VdcBllMessages.ACTION_TYPE_FAILED_HOST_NOT_EXIST)
.when(getVds() == null);
When expecting a positive outcome, instead of using:
return
FeatureSupported.nonVmNetwork(getDataCenter().getcompatibility_version())
? ValidationResult.VALID
: new
ValidationResult(VdcBllMessages.NON_VM_NETWORK_NOT_SUPPORTED_FOR_POOL_LEVEL);
use:
return
ValidationResult.failWith(VdcBllMessages.NON_VM_NETWORK_NOT_SUPPORTED_FOR_POOL_LEVEL)
.unless(FeatureSupported.nonVmNetwork(getDataCenter().getcompatibility_version()));
2. To lock a block of code, instead of using [1]:
lock.lock();
try {
// Thread safe code
} finally {
lock.unlock();
}
use:
try (AutoCloseableLock l = new AutoCloseableLock(lock)) {
// Thread safe code
}
[1] This is best used with locks from java.util.concurrent.locks package.
For regular thread safe blocks it's best to use the standard synchronized
block.
Regards,
Mike
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel