2:14 p.m.
We would likely specify different component/discovery classes in the JBAS 5 rhq-plugin.xml
descriptor
So right now we have things like:
<service name="Local Transaction"
class="JndiResourceComponent"
discovery="JndiResourceDiscoveryComponent"
While in the JBAS4 descriptor we have
<service name="VHost"
discovery="JBossASTomcatVHostDiscoveryService"
class="JBossASTomcatVHostService"
So within the plugin you've got control over how resources types are discovered, e.g.
lookup via mbean server or profile service.
Cheers
Charles
----- "Scott Stark" <sstark(a)redhat.com> wrote:
How are we going to know whether to look to an mbean or a
ManagedComponent in AS5?
Charles Crouch wrote:
> [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
> _______________________________________________
> jopr-dev mailing list
> jopr-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jopr-dev
>