10:28 a.m.
[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
2:07 p.m.
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
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
>
5864
days inactive
5864
days old
2 comments
2 participants
participants (2)
-
Charles Crouch -
Scott Stark