Vojtech Szocs has posted comments on this change.
Change subject: userportal,webadmin: update branding manager
......................................................................
Patch Set 5: (4 inline comments)
....................................................
File
backend/manager/modules/utils/src/main/java/org/ovirt/engine/core/utils/branding/BrandingManager.java
Line 72: /**
Line 73: * Constructor that takes a {@code File} object to configure the
brandingRootPath.
Line 74: * @param etcDir A {@code File} pointing to the branding root path.
Line 75: */
Line 76: private BrandingManager(final File etcDir) {
Yeah, but why should a unit test create instance via getInstance() and not via
package-private constructor?
In other words, having private constructor is no better than having
package-private constructor. Anyone can still use reflection to invoke any
constructor. But with package-private constructor, unit test can create
instance directly and doesn't have to mess with getInstance static method.
Line 77: brandingRootPath = new File(etcDir, BRANDING_PATH);
Line 78: }
Line 79:
Line 80: /**
Line 80: /**
Line 81: * Get an instance of the {@code BrandingManager} with the default
ETC_DIR.
Line 82: * @return A {@code BrandingManager}
Line 83: */
Line 84: public static synchronized BrandingManager getInstance() {
And Juan's code shows *exactly* what I wrote above - double-checked locking
which is actually meant to be AVOIDED in Java code due to problems with JVM
memory model.
The article I posted above gives detailed explanation on issues related to
double-checked locking.
Alon, you need synchronization when accessing singleton instance in
multi-threaded environment, so "synchronized" is necessary here. Your code
(without "synchronized") will not work properly in multi-threaded environment.
Line 85: if (instance == null) {
Line 86: instance = new BrandingManager();
Line 87: }
Line 88: return instance;
Line 80: /**
Line 81: * Get an instance of the {@code BrandingManager} with the default
ETC_DIR.
Line 82: * @return A {@code BrandingManager}
Line 83: */
Line 84: public static synchronized BrandingManager getInstance() {
I agree that having to pay synchronization penalty on method level is still a
feasible compromise. I mean, if instance creation isn't heavy-weight, what's
the big deal anyway.
Line 85: if (instance == null) {
Line 86: instance = new BrandingManager();
Line 87: }
Line 88: return instance;
Line 164: * @param prefix The prefix to use for getting the keys.
Line 165: * @param locale The locale to get the messages for.
Line 166: * @return A {@code Map} of keys and values.
Line 167: */
Line 168: private Map<String, String> getMessageMap(final String prefix,
final Locale locale) {
OK, it was just my suggestion, I'm fine with current approach too.
Line 169: List<BrandingTheme> messageThemes = getBrandingThemes();
Line 170: // We need this map to remove potential duplicate strings
from the resource bundles.
Line 171: Map<String, String> keyValues = new HashMap<String, String>();
Line 172: if (messageThemes != null) {
--
To view, visit http://gerrit.ovirt.org/15579
To unsubscribe, visit http://gerrit.ovirt.org/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: I87f5a6684701c9d5f603bf79459a3a5b6614b24f
Gerrit-PatchSet: 5
Gerrit-Project: ovirt-engine
Gerrit-Branch: master
Gerrit-Owner: Alexander Wels <aw...@redhat.com>
Gerrit-Reviewer: Alexander Wels <aw...@redhat.com>
Gerrit-Reviewer: Alon Bar-Lev <alo...@redhat.com>
Gerrit-Reviewer: Einav Cohen <eco...@redhat.com>
Gerrit-Reviewer: Greg Sheremeta <gsher...@redhat.com>
Gerrit-Reviewer: Michael Pasternak <mpast...@redhat.com>
Gerrit-Reviewer: Vojtech Szocs <vsz...@redhat.com>
Gerrit-Reviewer: oVirt Jenkins CI Server
_______________________________________________
Engine-patches mailing list
Engine-patches@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-patches
