JBoss Bean Deployer - JMX Integration

[adrian.brock]

I know we said we weren't going to worry too much about JMX integration in JBoss4.
But it should be possible to provide some basic integration at the deployment level,
e.g.

<?xml version="1.0" encoding="UTF-8"?>

<deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="urn:jboss:bean-deployer bean-deployer_1_0.xsd"
 xmlns="urn:jboss:bean-deployer">

 <loader-repository>
 dot.com:loader=test
 </loader-repository>

 <depends>jboss:service=TransactionManager</depends>

 <bean name="Name1" class="test.Hello">
 <property name="prop">Property</property>
 </bean>
</deployment>

Where "loader-repository" and "depends" are the standard JMX MC notions.

The main issue is how to do this while minimizing the "kludges" we have to support
for backwards compatibility when there is a real integration between the JMX and POJO
MCs.

[starksm64]

If we add a full object name alias notion to the jmx mc service layer, the depends notion can be the same as jbas5 in terms of a simple name.

The only scenario where I can see needing to specify a loader-repository is if a standalone bean deployment needs to use the scoped namespace of another legacy deployment. This is a rather exotic deployment for most users.

If your just talking about allowing a standalone bean deployment to use a scoped class loader, can't we just use a bean reference to a class loader configuration and embed the configuration in the target bean?

[adrian.brock]

If we add a full object name alias notion to the jmx mc service layer, the depends notion can be the same as jbas5 in terms of a simple name.

I'm not sure I like the idea of introducting yet another arbitrary naming space.
Though I do agree that logical names are important.

I would prefer the "alias notion" to be based on something more concrete, like.
a contract rather than just an ad hoc notion.

 <mbean code="org.jboss.tm.TransactionManagerService"
 name="jboss:service=TransactionManager"
 xmbean-dd="resource:xmdesc/TransactionManagerService-xmbean.xml">
 <attribute name="TransactionTimeout">300</attribute>
 <!-- set to false to disable transaction demarcation over IIOP -->
 <attribute name="GlobalIdsEnabled">true</attribute>
 <depends optional-attribute-name="XidFactory">jboss:service=XidFactory</depends>
 <!-- depends optional-attribute-name="RecoveryLogger" proxy-type="org.jboss.tm.recovery.RecoveryLoggerInstance">jboss:service=RecoveryLogger</depends-->
 </mbean>

 <bean interface="javax.transaction.TransactionManager"
 <factory bean="jboss:service=TransactionManager" method="getInstance"/>
 </bean>

 <bean name="MyBean">
 <property name="TM"><inject interface="javax.transaction.TransactionManager"/></property>
 </bean>

And ideally, this type of monomorphic (one implementor of the contract) behaviour would
be "automatic" without the too much need for explicit declaration.

 <bean name="MyBean">
 <property name="TM"><inject/></property> <!-- optional? -->
 </bean>

There are other dependencies that are not directly related to injection,
but have some logical component:

<deployment>
 <depends implementation="javax.jms" version="1.5"/>
 <bean name="MyBean"/>
</deployment>

[adrian.brock]

If we are to have an alias scheme, I would prefer it to have some sort of "type"
that could be used to identify mbean automatically, e.g.

<depends type="Queue" name="testQueue"/>
is
jboss.mq.destinations:service=Queue,name=testQueue

Otherwise you're going to either need to explicity declare aliases
in the MBeans or get the relevent MBeans to populate the alias database
in such as a way that they don't conflict.

[starksm64]

How is the type enabling the namespace management? In you example it would seem that you are carving out a Queue namespace that can be augmented with keys known to be unique in the Queue namespace. So you want a type based name to ObjectName mapping function on the alias aspect of the SARDeployer?

[adrian.brock]

Yes, I would segment the namespace by type IF I were going to do it that way.

The trouble is that it relies on something that does not really exist, i.e.
some notion of an abstract Queue MBean or class/grouping of such MBeans.

Such a notion could be retrofitted to the MBeans with a
getAliasType()/getAliasName()
but that is pretty intrusive to the implementation
or it requires more xml in the deployment to state it,
or it requires another listener on deployments to generate the alias database
from known patterns in MBean deployments (often with those patterns being conventions
only).

[starksm64]

So use both an explicit alias attribute on the legacy mbean for complete control, and allow for a mapping function on the SARDeployer to transform ObjectNames meeting understood patterns to be transformed into a unique alias. The latter should generally be universially applicable as one would expect a convention was in place for all object names.

[adrian.brock]

Yes, but surely all that does is introduce a binding to the new alias notion
rather than the ObjectName.

This might be useful for solving some problems like specifying the default datasource
(which already has an alias in that DefaultDS is already "hardwired" is some places)

To solve some other problems you would need to be able to specify an alias
based on some other name. e.g. automatically adding dependencies on
resource-refs based on jndi-name or ejb-refs based on ejb-name
i.e.

<depends type="ejb" name="MyEJB"/>
would resolve to
jboss.j2ee:service=EJB,jndiName=MyEJB
but this also depends upon context as well since MyEJB can exist in multiple
deployments.

I don't think adding a "trivial" alias notion would solve many problems,
and it would likely confuse some users. Users are confused enough
when the MBeans are created by deployers so they don't know what
names to use.

Instead, we should be working towards defining an
extensible dependency notion that understands context, type or anything
else that might be important.
This should produce something intuitive and allow users to "write their own
dependency" if nothing fits what they need.

[starksm64]

Ok, but we seem to be mixing legacy vs future naming issues. Just throwing an alias attribute onto the existing mbean would seem to ease integration of non-jmx based stuff into the jmx mc, and avoids the exposure of a jmx name dependency in the new bean deployer.

[adrian.brock]

Yes, but as I said above, I want to "minimiz(e) the kludges".

This can be done by introducing something that is based on what we want
going forward (even if it is incomplete).

e.g. when I've integration the jmx/pojo MCs
the injection should be "transparent" between the two. The transaction manager
factory above, doesn't really know that it is using an MBeanProxy on the
TransactionManagerService.

The problem before that integration (jboss4) is that the lifecycles or
configuration spaces aren't linked, except that the whole bean deployment is
managed by an MBean known to the SARDeployer.

I can hack some things to make it work better, but it isn't going to work as well
as the real solution in JBoss5.
There is sort of cross over here, in that we still want the old loader-repository
config to work in JBoss5, even when the classloaders are part of the DI framework.

[starksm64]

So what is the "minimiz(e) the kludges" approach?

[adrian.brock]

So what is the "minimiz(e) the kludges" approach?

I don't know yet.
If it was trivial, I probably wouldn't have mentioned the issue in the forums :-)

The issue is to spot that a dependency/injection is really an external dependency
outside the control of the bean MC and preprocess them into "depends"
to attach to the ServiceController registration, i.e. the wrapping container.

Anyway, we said we weren't going to worry too much about the JMX integration
for JBoss4 (at least in the initial release).

[starksm64]

So I'm not seeing why its not as simple as injecting an object name pattern matcher to the sar deployer that returns the string alias:

interface TheMinimalHackThing
{
 String mapObjectNameToAlias(ObjectName name);
 String getAlias(ObjectName name);
 ObjectName getObjectName(String alias);
}

[adrian.brock]

I'm not sure I follow, I think we have got a bit off-topic :-)

Certainly, I could make it a rule that if the depends or inject tag in the bean's xml
has a name that is a valid ObjectName, then it is assumed to
be a jmx dependency. This logic can be hidden away in the deployer/dependency
processing of JBoss4's BeanDeployer.

Whether we want to keep the jmx ObjectName as the namespace convention
down the road is a different issue. It does have some advantages in terms
of the flat namespace and querying, but it fails in its original intention of being a "logical"
name for the underlying object (which is probably partly a fault of the way we use it).

In many ways, querying on the real attribute/property values is probably better?

Like I expressed above, I don't think that just a name is necessarily the best/only way
to do this. Though using any other scheme will still require at least an internal unique "id".

[starksm64]

I think we are still on topic target, its just a question of how the bean deployer is implementing the depends tag. Maybe I'm confusing the issue with the belief that the bean deployer already has a depends tag. That is what I am thinking and the question is one of making the jmx mc components available as dependencies targets in the bean deployers.

As you said, this has a straightforward impl if one uses the jmx mc component object name, and the bean deployer assumes valid jmx names refer to components in the jmx mc.

Beyond that is the question of mapping the jmx mc names into a non-jmx object name namespace for more natural pojo mc naming convention. Its a notion that has validity purely in the jmx mc as well given that there are more logical names/aliases for many services.

For the not so logical names such as that assigned to an ejb local home or mdb deployment, there really is no natural name other than the existing ejb-name, but its far from being unique. I'm punting on this for now.