Red Hat Bugzilla – Bug 918031
JON plugin for BRMS doesn't meet plug-in standards for which a JBoss ON user is used to
Last modified: 2013-08-27 19:56:08 EDT
Larry, who is a JON expert in GSS, pointed out that JON plugin for BRMS doesn't meet plug-in standards for which a JBoss ON user is used to. ====== 1) BRMS plugin requires the user to configure a JMX server even in EAP instance. 2) it requires the user to configure a JMX server resource in JBoss ON. This introduces multiple issues but primarily: - The JMX plug-in is not supported directly. Only via other plug-ins, so it is the Drools plug-in job to handle this itself as part of is discovery process. - User's of JBoss ON are not developers. They are IT/IS associates or administrators within an enterprise or production settings. Primarily, an application developer would not have the necessary permissions to create the resources that are currently required in order to get a drools instance into JBoss ON. 3) from what was described about the Drools MBeans life-cycle, the user will always be in a battle to manage or monitor a Drools deployment from JBoss ON because it will keep flipping between available and unavailable. Please keep in mind that JBoss ON is not real-time. Many of its tasks are on a schedule that ranges anywhere from 5 minutes to an hour. What this means is that if the MBean comes and goes as it pleases, the user will always see this as an error condition. ====== Suggestion from him: ====== -> 1) The Drools deployment, regardless of whether we reach it via JMX or via EAP's management interface, needs to appear under the AS parent. Just like all the other items that get deployed to AS. This is true whether it is added manually or automatically. If there is a valid and supported use-case that a drools deployment run in a standalone JVM or within another application container, we should determine if the deployment is running in AS and if it is, put it under AS. If it is not, put it under a generic JMX server. I am referring to the resource hierarchy. -> 2) The plug-in should handle the discovery of the drools deployment on its own. At a minimum, it should handle the manual import of an existing Drools deployment. So instead of me importing a generic JMX server, I should have an option to manually import a Drools container, which under the covers might still be JMX but all the required configuration and class paths are configured for the user. The goal should be to make this an automatic process or in the case that automatic didn't find it, the user can easily deploy. We should probably also include a Create New option within the BRMS subsystem that a Drools deployment will end up in. This will allow me to deploy from the BRMS hierarchy and immediately see my deployment where I expect in the BRMS hierarchy. -> 3) if the drools deployment isn't something that is always there, then perhaps monitoring should be completely disabled for the resource or at a minimum, availability checks be disabled. ======= Similar topic has been discussed in BZ730367 https://bugzilla.redhat.com/show_bug.cgi?id=730367
Sorry about raising this before splitting into clear BZs because this topic is cross-domain and there is less information about this plugin. I have also raised BZ918033 for documentation. If the documentation clarifies BRMS plugin specification (how different from other plugins by design), I may be able to split this BZ into some simpler BZs (bug or feature request).
Assigning Edson. Edson, I keep this BZ open as you commented. Please let me know if you want to split this BZ and raise community JIRAs. Thanks, Toshiya
This BZ has been moved from JON to BRMS product because this plug-in is under control of BRMS project.