jbas4 and jbas5 plugin code sharing
by Charles Crouch
[re-posting in a new thread]
I think we need to have some code sharing going on between the jbas4 and 5 plugins for the following reasons:
1) The Embedded JMX discovery (currently, when jmxremoteport is not set) uses the parent's (JBAS) EMS connection to connect to the MBean server. In order for a JBAS5 resource to utilize the same mechanism for discovering its JVM MBeanserver its going to need to have this EMS connection.
2) At least initially not all the the JBAS5 services are going to have their stats and operations exposed via the profile service. For those that don't I think we want the option of using any exposed mbeans (of which there may be some) to support stats and operations.
In order for 1) or 2) to be achieved a JBAS5 resource is going to need to do the exact same jnpurl/principal/credentials stuff that the JBAS4 plugin does currently to connect to its MBean Server. Given this, it would seem reasonable to share some of the utility code which does this magic:
In embedded jopr I've got the JVM resource being discovered via the JBAS5 plugin using the following
Classes copied into jbas5 plugin from jbas4 plugin:
JBossInstallationInfo
JBossMBeanUtility
JBossProductType
JBossProperties
Methods copied virtually unchanged into ProfileJBossServerDiscoveryComponent (plus some static strings)
JBossASDiscoveryComponent.discoverJBossPcIsEmbeddedIn()
To get this fully working for Jopr as well we'll probably need some variants of processAutoDiscoveredProcesses() and processManuallyAddedResources().
Methods copied virtually unchanged into ProfileJBossServerComponent (plus some static strings)
JBossASServerComponent.stop()
JBossASServerComponent.getEmsConnection()
JBossASServerComponent.loadConnection()
To avoid this duplication there seem to be a number of options:
1) Including the jbas4 classes via an rhq-plugin import of the jbas4 plugin seems overkill for the embedded case. We don't need to ship a 2mb jbas4 plugin in the embedded 5.0 console.
2) Some sort of new module (jbas-plugin-util.jar) containing the shared classes. Each plugin could then pick what it wanted to use/extend from here
3) Munge the 2 jbas plugins. There is going to be some shared stuff across the plugins, but I'm not sure both are going to need the same dependencies.
Some of the size issues around 1) and 3) would go away if we could pull out
http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/ant...
and just incorporate it into the com.jboss.jbossnetwork.product.jbpm.handlers.UnzipActionHandler. That way we could get rid of 1mb of ant.jar
Thoughts?
Cheers
Charles
15 years, 4 months
- 2
- 2
- ← Newer
- 1
- Older →