Ravi Nori has posted comments on this change.
Change subject: engine: Add infrastructure code for removal of parameter classes
......................................................................
Patch Set 14:
(4 comments)
....................................................
File
backend/manager/modules/common/src/main/java/org/ovirt/engine/core/common/action/VdcActionParametersBase.java
Yes definitely we should do that. We should even rename this class as it will
not be parameters base anymore, it will be just plain parameters class. Not
sure if we should do that now or as a final patch after we are done removing
all parameter classes. What do you think?
Line 1: package org.ovirt.engine.core.common.action;
Line 2:
Line 3: import java.util.ArrayList;
Line 4: import java.util.List;
....................................................
File
backend/manager/modules/common/src/main/java/org/ovirt/engine/core/common/utils/InvalidParameterUuidException.java
Line 1: package org.ovirt.engine.core.common.utils;
Line 2:
Line 3: public class InvalidParameterUuidException extends
IllegalArgumentException {
Line 4:
Line 5: public InvalidParameterUuidException(String name, String uuid,
String existingName) {
You mean also show the type of the conflicting parameter or UUID uuid in
parameters list
Line 6: super("Invalid value for uuid " + uuid + " for Parameter " +
name +
Line 7: ". A parameter with the same uuid already exists " +
existingName);
Line 8: }
Line 9:
....................................................
File
backend/manager/modules/common/src/main/java/org/ovirt/engine/core/common/utils/VdcParameter.java
Line 10: private final String name;
Line 11: private final Class javaType;
Line 12: private final UUID uuid;
Line 13: private static final Map<UUID, VdcParameter> parametersMap = new
HashMap<UUID, VdcParameter>();
Line 14: private static final int VERSION = 0;
will do
Line 15: private static final String VERSION_KEY = "version";
Line 16: private static final String UUID_KEY = "uuid";
Line 17:
Line 18: private VdcParameter(String name, Class javaType, UUID guid) {
....................................................
File
backend/manager/modules/common/src/main/java/org/ovirt/engine/core/common/utils/VdcParametersMap.java
It is a very good question and I considered doing that too. But we are giving
this class part of map functionality and want to control the put method, it is
ideal to do this by composition rather than inheritance (extends).
This is a recommend way of doing things according to Joshua Bloch's Effective
Java "Item 16 : Favor composition over inheritance". He explains why it would
be problematic to just extend from Collections when we want to control the
add/put functionality.
Line 1: package org.ovirt.engine.core.common.utils;
Line 2:
Line 3: import java.io.Serializable;
Line 4: import java.util.Collections;
--
To view, visit http://gerrit.ovirt.org/20414
To unsubscribe, visit http://gerrit.ovirt.org/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: I6a0970e492c0eff561888a46b02e47645ff68fc3
Gerrit-PatchSet: 14
Gerrit-Project: ovirt-engine
Gerrit-Branch: master
Gerrit-Owner: Ravi Nori <rn...@redhat.com>
Gerrit-Reviewer: Alon Bar-Lev <alo...@redhat.com>
Gerrit-Reviewer: Barak Azulay <bazu...@redhat.com>
Gerrit-Reviewer: Liran Zelkha <lzel...@redhat.com>
Gerrit-Reviewer: Ravi Nori <rn...@redhat.com>
Gerrit-Reviewer: Yaniv Bronhaim <ybron...@redhat.com>
Gerrit-Reviewer: mooli tayer <mta...@redhat.com>
Gerrit-Reviewer: oVirt Jenkins CI Server
Gerrit-HasComments: Yes
_______________________________________________
Engine-patches mailing list
Engine-patches@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-patches
