[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