Yair Zaslavsky has posted comments on this change. Change subject: aaa: extension-manager: prepare to multiple binding support ......................................................................
Patch Set 1: (3 comments) http://gerrit.ovirt.org/#/c/27280/1/backend/manager/modules/extensions-api-root/extensions-api/src/main/java/org/ovirt/engine/api/extensions/Base.java File backend/manager/modules/extensions-api-root/extensions-api/src/main/java/org/ovirt/engine/api/extensions/Base.java: Line 55: * Jboss module binding method jboss module name. Line 56: * <br> Line 57: * Mandatory. Line 58: */ Line 59: public static final String BINDINGS_JBOSSMODULE_MODULE = "ovirt.engine.extension.binding.jbossmodule.module"; can we put specific binding methods properties (such as JBOSS MODULE MODULE + JBOSS MODULE CLASS) in a separate "namespace" ? that is, some static inner class? What do you think? Line 60: /** Line 61: * Jboss module binding method class name. Line 62: * Used to locate the service at META-INF/services/<class>.Extension. Line 63: * <br> Line 75: * Binding methods. Line 76: */ Line 77: public static class ConfigBindingsMethods { Line 78: /** Line 79: * Jboss module binding method. is this comment really related only to jboss module binding? if so, please explain why. thanks. Line 80: * Use Jboss module loading method and Java bindings. Line 81: * <pre> Line 82: * public class MyExtension implements Extension { Line 83: * {@code http://gerrit.ovirt.org/#/c/27280/1/backend/manager/modules/extensions-manager/src/main/java/org/ovirt/engine/core/extensions/mgr/ExtensionsManager.java File backend/manager/modules/extensions-manager/src/main/java/org/ovirt/engine/core/extensions/mgr/ExtensionsManager.java: Line 62: exception); Line 63: } Line 64: } Line 65: Line 66: private Class<?> lookupService(Class<?> serviceInterface, String serviceClassName, String moduleName) { Bare in mind this part has to do with SPI, and not necessarily JBoss module. For example, I may pack my extension classes + the SPI file in some archive, and then develop a custom class loader that will extract the information. Worth considering to "utilizing" this somehow if in the future we might want to reuse it . Line 67: // Iterate over the service classes, and find the one that should Line 68: // be instantiated and initialized. Line 69: Module module = loadModule(moduleName); Line 70: Class<?> serviceClass = null; -- To view, visit http://gerrit.ovirt.org/27280 To unsubscribe, visit http://gerrit.ovirt.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: Iab0b2efa0ac95c05a3e682bdf51e528a32b3f84a Gerrit-PatchSet: 1 Gerrit-Project: ovirt-engine Gerrit-Branch: master Gerrit-Owner: Alon Bar-Lev <[email protected]> Gerrit-Reviewer: Alon Bar-Lev <[email protected]> Gerrit-Reviewer: Yair Zaslavsky <[email protected]> Gerrit-Reviewer: [email protected] Gerrit-Reviewer: oVirt Jenkins CI Server Gerrit-HasComments: Yes _______________________________________________ Engine-patches mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-patches
