6.6. Exposing POJOs as MBeans

Example 6.8. Exposing an Existing POJO as an MBean

<deployment xmlns="urn:jboss:bean-deployer:2.0">

  <bean name="AnnotatedJMXPojo" class="org.jboss.demos.models.jmx.AtJmxPojo"/>

  <bean name="XmlJMXPojo" class="org.jboss.demos.models.mbeans.Pojo">
    <annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(exposedInterface=org.jboss.demos.models.mbeans.PojoMBean.class, registerDirectly=true)</annotation>
  </bean>

  <bean name="ExposedPojo" class="org.jboss.demos.models.jmx.Pojo"/>

  <bean name="AnnotatedExposePojo" class="org.jboss.demos.models.jmx.ExposePojo">
    <constructor>
      <parameter><inject bean="ExposedPojo"/></parameter>
    </constructor>
  </bean>

</deployment>
			
			
			

This descriptor exposes an existing POJO as an MBean, and registers it into an MBean server.
To expose a POJO as an MBean, end it with an @JMX annotation, assuming that you have imported org.jboss.aop.microcontainer.aspects.jmx.JMX. The bean can either be exposed directly, or in its property.

Example 6.9. Exposing a POJO as an MBean Using Its Property

<deployment xmlns="urn:jboss:bean-deployer:2.0">

  <bean name="XMLLoginConfig" class="org.jboss.demos.models.old.XMLLoginConfig"/>

  <bean name="SecurityConfig" class="org.jboss.demos.models.old.SecurityConfig">
    <property name="defaultLoginConfig"><inject bean="XMLLoginConfig"/></property>
  </bean>

  <bean name="SecurityChecker" class="org.jboss.demos.models.old.Checker">
    <property name="loginConfig"><inject bean="jboss.security:service=XMLLoginConfig"/></property>
    <property name="securityConfig"><inject bean="jboss.security:service=SecurityConfig"/></property>
  </bean>

</deployment>
			
			
			

You can use any of the injection look-up types, by either looking up a plain POJO or getting a handle to an MBean from the MBean server. One of the injection options is to use type injection, sometimes called autowiring, and shown in Example 6.10, “Autowiring”.

Example 6.10. Autowiring

<deployment xmlns="urn:jboss:bean-deployer:2.0">

  <bean name="FromGuice" class="org.jboss.demos.models.plain.FromGuice">
    <constructor><parameter><inject bean="PlainPojo"/></parameter></constructor>
    <property name="guicePojo"><inject/></property>
  </bean>

  <bean name="AllPojos" class="org.jboss.demos.models.plain.AllPojos">
    <property name="directMBean"><inject bean="jboss.demos:service=pojo"/></property>
    <property name="exposedMBean"><inject bean="jboss.demos:service=ExposedPojo"/></property>
    <property name="exposedMBean"><inject bean="jboss.demos:service=ExposedPojo"/></property>
  </bean>

</deployment>
			
			
			

The FromGuice bean injects the Guice bean via type matching, where PlainPojo is injected with a common name injection. Now, you can test if Guice binding works as expected, as shown in Example 6.11, “Testing Guice Functionality”.

Example 6.11. Testing Guice Functionality

public class FromGuice {
    private IPojo plainPojo;
    private org.jboss.demos.models.guice.Pojo guicePojo;

    public FromGuice(IPojo plainPojo)
    {
	this.plainPojo = plainPojo;
    }

    public void setGuicePojo(org.jboss.demos.models.guice.Pojo guicePojo)
    {
	this.guicePojo = guicePojo;
    }

    public void start()
    {
	f (plainPojo != guicePojo.getMcPojo())
	    throw new IllegalArgumentException("Pojos are not the same: " + plainPojo + "!=" + guicePojo.getMcPojo());
    }
}
			
			
			

Example 6.11, “Testing Guice Functionality” only provides an alias component model. The alias is a trivial, but necessary feature. It must be introduced as a new component model inside the Microcontainer, in order to implement it as a true dependency. The implementation details are shown in Example 6.12, “AbstractController Source Code”.

Example 6.12. AbstractController Source Code

<deployment xmlns="urn:jboss:bean-deployer:2.0">
  <alias name="SpringPojo">springPojo</alias>
</deployment>
			
			
			

This descriptor maps the SpringPojo name to the springPojo alias. The benefit of aliases as true component models is that timing of bean deployment becomes less important. The alias waits in a non-installed state until the real bean triggers it.