Description of problem: Our poor design of JBossProductType enum limits us in extending it. In order to fix Bug 1218307 we need to define just another value in JBossProductType enum, because the discovery code fails, in case it is not able to determine productType based on slot value in product.conf or a using homeDir name as a fallback. Long time ago, we implemented DiscoverCallback feature to plugin descriptor to handle these kind of situations, but this is not enough. DiscoveryCallback would work, if JBossProductType enum is detected (in case proudct.conf ie. contains slot=eap). Plugin extending AS7Plugin could then fix plugin configuration like https://github.com/gatein/gatein-rhq/blob/master/src/main/java/org/gatein/rhq/plugins/PortalDiscoveryCallback.java does. Given code is only a workaround to a fact, that gatein plugin has slot defined to "jpp" or "eap", and at runtime DMR returns "Portal" string as a response to :read-attribute(name=product-name). Gatein plugin (an all other AS7based plugins) still relies on AS7plugin and JBossProductType. Version-Release number of selected component (if applicable): JON 3.3.x Actual results: new AS7 Based plugin which manages product with slot=foo new requires fix in AS7 plugin - defining JBossProductType, otherwise product server discovery fails on bugs similar to Bug 1218307 Expected results: new AS7 based plugin which manages product with slot=foo must not require fix & rebuild of base AS7 plugin Additional info:
Initial idea was transforming JBossProductType from enum to class and use java ServiceLoader interface, so other plugin could contribute to some "known products registry" living in base AS7 plugin. This did not work because of plugin container design and plugin classloader's isolation. To fix this issue I'll introduce JBossProductType to JBossProduct class and redo product type discovery logic (creating JBossProduct instance based on slot value) into JBossProduct instance. Product Discovery logic in Base plugin will return JBossProduct.unknown() in case it detects slot value, which it cannot assign to any known product definition. This unknown product type could then be detected by DiscoveryCallback implementations, which can then set correct values to pluginConfiguration and properly set resource name and description version. I'll introduce abstract DiscoveryCallback implementation which plugin can extend and only define it's JBossProduct.
Closing as won't fix. Although this capability would be very helpful for Red Hat and JBoss branding as it would no longer require a completely new EAP plug-in pack each time a new product was introduced or changed its name or identifier, the risk and effort is not worth the return. This is because we are so late in the 3.3 maintenance cycle and many of the naming changes that have occurred over the past 24 months have slowed down. Additionally, we have decided to introduce a change in the EAP plug-in (tracked in bug 1300727) that will treat any unknown or unidentifiable EAP based product as a community AS instance. This will provide basic application server monitoring and management for the edge cases in where a rebrand may occur.